New: OAuth for MCP Servers — Lessons from Building for AI Agents

0:00Hey everyone, I'm Pete. Welcome back to Semaphore product news. Today's episode is a deep dive into how we implemented OAuth for our MCP server and what it takes to make authentication work in a fast moving ecosystem of AI agents. As we continue evolving Semaphore beyond traditional CICD into a platform for running agent-driven workflows, secure authentication becomes a key foundation. In this conversation, Marco, Damjan and Amir walk through the challenges, trade-offs, and practical lessons from building this in the real world. Let's get into it. We have Damjan, our head of engineering, and Amir, our engineer here to talk about MCP server and especially the OAuth implementation of OAuth in MCP server and what are all the things that in the nice things that they learned while they were working on that functionality. So guys, tell us more.

1:00Amir was the main lead on developing this new feature, so Amir, if you can maybe give us a short intro, maybe just about how all works because I'm sure that almost everyone knows what is and then we can talk a bit more about main challenges introducing this old feature for our MCP server. So for MCP, OAuth is a way to, so basically all of the agents now provide an easy way to authenticate with MCP servers. I think initially you could only have like a local standard input output servers and then this was expanded with time to remote servers and then with remote servers you get the need for authentication. With authentication, you don't want to just rely on the API keys and then here comes the OAuth. But it's tricky since there are a lot of providers and then there's also many clients or agents and also different ways of these providers giving the OAuth for the client.

2:13So one of the major challenges for the MCP and OAuth there was client registration. So basically this is the part where the initiator of the OAuth needs to basically, how to say it like, forward the user with some client ID and secret to the OAuth provider. I'm going to probably miss the terminology here. So yeah, this is the main challenge with MCP since there are a lot of you, you don't know what the clients are, you don't know what the servers are. So the major thing here are actually how to do these two meet. So yeah, that's one of the things that started with the cost of the OAuth. Yeah, and while we were working on this, I remember you mentioning that the main problem with the client registration was because it was implemented in different ways in different agents, right?

3:17So not every agent supported it in the same way. Is that correct? Some big bit is being. Yeah, dynamic field. It was all over the place. Yes. So if I remember correctly, so before the client is registered, the agent has to discover some things about the server in order to actually register the client. And the MCP is protected resource for the client to get the OAuth. It has to discover some endpoints and know some things about the server, about authenticating server for this resource. Different clients use different way of getting to these discovery endpoints. These are just like public HTTP endpoints that have some data about the authentication server. And like if you have a slash MCP, one of them, some agents will go to slash MCP slash well known OAuth and some will go to slash MCP slash

4:21or slash well known slash OAuth slash MCP. Yeah, so subtle differences in URL there, but you can't handle each case, right? Yes, you don't see it until you test it. No, so some of the testing here was very interesting. You get to get your hands only to different number of agents, right? Yeah, one of the things, like I first tried, when I was like testing this, I tried out the official MCP server or MCP client thing from like the official one that has a web interface. And for it again, you have specific problems with that one because it's a client that you run locally, but you interact with the client through your web browser. So then there are some specific for that one course issues. And then even after those are solved, it doesn't really provide you with helpful errors while you try to debug what's going on.

5:26So luckily, I found out about MCP jam, which was very helpful in checking out which version of the MCP route will work with us. Can we say that we support and we transfer it on the MCP protocol or standard versions, right? Yeah, MCP spec. So different specs, again, the MCP spec is evolving over time. Last year, we had three different specs. I think if there is now that we check, maybe there's a new one now. But basically, yeah, so it's very dynamic field and stuff is changing almost every month. When we first started like working on the MCP of cloth didn't support pre-registered wealth clients. So it had to use this dynamic client registration. Like, as we said, which is a way for the client and the server to get to know each other and exchange some info. And now, while I was working on getting this to work, they basically added support for pre-registered clients.

6:35And then again, one other thing that cloth didn't support, I'm not sure if they do now, was custom-like providing cloth with what scopes you want to get from the allowed server. So they just get the default ones and then what that meant while we were using, while we were trying to use key cloak, that means that we had to inject scopes into the intercept request and then inject scopes that we require for the MCP. So for actually authenticating with the MCP. And so these scopes are mainly important for us to know to what level you authorized MCP to do actions in your behalf. So you can do different scopes, for example, providing read access only or read and write access. And that can get more granular as time goes and as we improve that part, is that correct?

7:38Yes, that's exactly right. So we couldn't do that initially with cloth, but now that's also possible. So you also mentioned key cloak, I noted that part is specific for our implementation of call authorization for. Provided some challenges while you were working on this, can you maybe tell us a bit more about specific issues with our implementation that made this part maybe not challenging, but a bit tricky too. So yeah, so basically I was tracking one one issue where on the key cloak side they were tracking if they support the everything for the MCP. Yeah, basically there was some minor issue based on these findings, but everything else should be supported and I started working on that. And pretty soon I found that even our way of using key cloak and how key cloak wants to do the MCP was like pretty different.

8:44Can we get a bit more into details here? So the way we are using key cloak currently is like we are only using it as authentication tool, not for managing the whole authorization cloak. For us it's basically like identity provider. Yeah, identity provider. For us it's basically identity provider that we only rely on for providing the identity and ensuring that ensuring like up to spec interaction with providers that we that users can authenticate with and also then. Like the self-hosted version yes and also several self-hosted versions you can yeah we use it as a again authentication and but mainly it's for us it's it's identity provider so do this authentication part being there was like okay it can work but I soon found like a lot of issues with how if we were basically to expand this to.

9:53We get more granular permissions for example per project or something like that it would be really tricky with key cloak. I assume the main main challenge there was the it's hard to make a cover of specific sort of authorization for some on our back inside right things about. Yes, part projects and organizations and like the different terms and like structures for that managing access essentially. Yes, so we don't use key cloaks stuff for that so that gets tricky when when they there are ways but we were like more comfortable writing a mix here and something we know about and getting everything in our hands like for control. So so eventually we wrote out that on solution for that right yes services that are managing authorization yes so we we we have is we have it split in two two different services final question here if you were to implement this from scratch again today with you approach it differently or like like are there any like major.

11:06Yeah, I would like not look at the spec maybe I mean that sounds crazy but yeah a lot of my yeah a lot of I trouble started like when I tried to understand the spec okay I'm looking at one version of the spec and then I try to follow that then I check okay what's the next spec and then there is like brand new thing this dynamic client registration is not there and I'm now learning about some CIMD I. I don't even remember now what it was but it's it doesn't exist basically it yet doesn't exist and it's a it's still like in very early early stages itself like this part is also like the mcp spec in very early stages so it's not yet possible to support that. If I understand you correctly so it would be better to focus on what is currently available with different agent providers rather than making sure that like the most recent spec is fully supported in the like most recent spec is maybe a month or old or yes I'm so exiled right right I think we we started looking into it like and the newest spec was quite quite fresh this is the first spec that I started looking at which had this.

12:27The IMD I don't remember what it is yeah it's a client ID metadata document which is again another way of thinking about client and the server knowing about each other like what are the redirect URLs and so on. Okay great well thank you for going into details here Amir it was really interesting sounds like it really interesting Mark would you have any questions for Amir here. Yeah yeah yeah so one thing is that so Amir you said like you know you would not like start with the latest specs but you know so for somebody that wants to start implementing the all out in their mcp server like you know what would be your like you know advice like you know where to start yeah I think the best version still to use is the one from March last year even though it's a year old I think it's the the healthiest one to follow still. The two new ones and the draft is still not not not there on the on the side of the agents you don't have the support from the agent to do something like codex doesn't support prompts that are advertised by the server maybe they do now but at least when I last used codex that was not supported.

13:45So like stuff is not supported that's even in this one year old spec so be very conservative that's your advice and you know yeah don't don't fly that everything is supported. Yeah and what's the best way to test just like good old fashioned like trying out multiple agents you know the agents of interest and then I used mcp gem inspector I feel like a great tool and they have like outflow where you can go step by step and and actually see. What the client is trying to do and what it gets back what doesn't match with the expectation so you get both both step by step and you can catch any issues there. And then after you see that mcp inspector is working then obviously you still need to check the specific clients or agents because as I said some use this introspection thing for finding the authentication URL some use this appending and then they need two different endpoints.

14:54Yeah perfect yeah thank you for that this level of detail I hope you know this will be you know extremely valuable for the folks. Okay great well we are looking forward for the you know what's coming next in our mcp server implementation journey well until then you know have a great day and you know until the next time. And that's it for today's episode and if you're curious to try this out yourself you can sign up for Simifor and start building your own agent powered workflows. Thanks for listening and till the next product update.