- Existing Microservice Communication Protocol (MCP) setups, relying on OAuth, force users through repetitive consent screens and provide limited visibility and control for IT administrators over application access and data security.
- Cross-App Access (XAA), powered by the IDJag specification, enables an Identity Provider (IDP) to act as a trusted intermediary, automating the secure exchange of credentials between MCP clients and servers.
- This solution eliminates the need for manual consent, centralizes access management for IT, and enhances security by allowing shorter-lived tokens and instant access revocation.
One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS
- Current MCP implementations using OAuth result in a poor user experience with "consent screens on top of consent screens" for each service connection.
- This traditional model lacks IT visibility into which MCP services and AI agents users are accessing, posing security risks regarding sensitive data and unapproved tools.
- Single Sign-On (SSO) systems are broken by traditional MCP, as applications don't inherently trust each other, forcing repeated authentication flows.
- Cross-App Access (XAA) (based on the IDJag specification) introduces the Identity Provider (IDP) as a trust provider to bridge communication between MCP clients and servers.
- Once a user logs into the IDP, the MCP client can automatically obtain credentials for connected MCP servers without further manual consent or interaction.
- XAA significantly improves security by allowing for very short-lived access tokens and enabling IT to centrally revoke access via the IDP, preventing lasting access issues if a user leaves or is compromised.
- For IT administrators, configuring XAA involves simply defining which MCP client applications are allowed to request access to specific MCP server applications within the IDP.
- MCP clients need an XAA-compatible SSO connection to the IDP, the ability to request IDJag tokens from the IDP, and to exchange these tokens for access tokens with MCP servers.
- MCP servers must support a new JWT bearer type, accept IDJag tokens, verify them with the IDP, and then issue standard access tokens to the client.
MCP client — An application or tool (e.g., Cursor, Claude Code) that connects to and consumes services from various MCP servers.
MCP server — A service or application (e.g., Figma, Notion) that exposes resources to be accessed by MCP clients.
IDP (Identity Provider) — A system responsible for authenticating users and providing identity information to other services (e.g., Octa, Microsoft Intra).
OAuth — An open standard for access delegation, often used for authorization where users grant client applications access to resources on a server.
SSO (Single Sign-On) — An authentication scheme that allows a user to log in with a single IDP and gain access to multiple connected applications without re-authenticating.
Cross-App Access (XAA) — A solution that allows an IDP to mediate trust and automatically issue credentials between an MCP client and an MCP server, eliminating manual user consent.
IDJag (Identity JWT Authorization Grant) — The technical specification behind Cross-App Access, defining a token issued by an IDP that can be used across services to manage access.
Access Token — A credential issued by an authorization server to a client, granting access to specific protected resources.
Refresh Token — A credential used to obtain a new access token without requiring the user to re-authenticate, typically having a longer lifespan than an access token.
SCEM — A system or standard used by IT to fully revoke user access to applications, typically in scenarios like offboarding or security incidents.
DCR (Dynamic Client Registration) — A standard that allows OAuth clients to dynamically register themselves with an authorization server, rather than being pre-registered.
All right, good morning, everybody. Thank you for coming to this talk. Hopefully your morning was eventful. I caught a little bit of the keynote and I wasn't able to catch all of it, but it was pretty good. My name's Gary Galo. Today I'm going to be talking about one login to rule the mall, or cross-up access for MCP, in case you haven't heard about that. Quick intro about myself. I run product at WorkOS. I've been building enterprise developer platforms for the past almost 15 years, originally in Microsoft Azure, then a Cloudflare for a long time, and now at WorkOS. If you haven't heard of WorkOS before, we make your app and also your agents enterprise ready. We power off for the likes of Anthropic, Cursor, OpenAI. So if you've ever logged into cursor, for example, whether that was with username password or an enterprise IDP, you've used WorkOS. Today I'm going to be talking about MCP and sign in through things like Anthropic and Cursor. But first, if you use MCP at all extensively, you know that it means consent screens on top of consent screens on top of consent screens. Who here uses MCP servers on the regular? OK, most of you. If you haven't kind of experienced this before, here is cursor, which I have set up. And if you want to use MCP servers with cursor, you add the menu, you have a little config file. And then in each one of these, if you want to use it, you have to connect. It'll pop up this window. You have this nice little consent screen that you're not going to read. You're just going to say OK, and you're going to get redirected back. And you need to do this for every single tool, which is frankly pretty annoying. And sometimes you have to do this again. You don't really know why. Sometimes you have to do this again. Sometimes it seems to forget that you've already done this. Yeah, and so this is like a thing you have to do every time you want to use these MCP servers. And that's not fun. But it's in the company with a lot of developers. It's not just one person's inconvenience. As a user, you might log into half-dozen or a dozen MCP servers. But when you combine that together across your team, you basically have dozens and dozens of people spending all this time managing all these consent screens, clicking these buttons. So without really caring why they have to do this. Now this is a relic of a lot of the technology that MCP decides to use. It uses OAuth as an underlying authentication layer. And so the way OAuth was kind of invented around was the thing of like, you know, these two systems don't trust each other. So you have to like provide this consent to say, yes, cursor can have access to my Figma account. Yes, cursor can have access to my notion account. But the reality is that's not really how things operate today. It's not how companies operate. We have a thing called single sign on. Most people are using it. If you have a company, you're logging in through something, an Octa or Microsoft Intra, one of these systems. And that's sort of that idea of one login signed into all those applications worked great. But MCP breaks this model. It sort of assumes that none of these apps know anything about each other. There's no way to know that you're the same person that you should have access to these systems. So you have to go through these flows over and over and over and over again. Now that is really annoying. And maybe that unto itself is a problem worth solving. But humans will tolerate a lot of annoyances if they get value out of it. The real problem comes in for the IT team. Like the people managing all these applications, MCP doesn't work the way that they want it to work. IT can't really tell what MCP service you may or not be using. You're connecting to these arbitrary things. You're not necessarily going through that IDP to connect to them, which is problematic. They basically can't determine which AI agents you can actually use. In theory, you can take any arbitrary MCP client. That might be a cursor, but you could be using a deep seek or some of these other tools that maybe your IT team doesn't want you to use. And you're granting access to these sensitive systems. You have lots of data and things like Figma or Notion that IT maybe doesn't want any AI agent to get access to. The other thing is actual access and security. I don't know how many people heard about the NPM Axios package getting popped about a week ago. Unfortunately, I was hit by that. I'm still not exactly sure what NPM package thing I used that had that dependency. But RIT team became aware of that problem. They were able to detect that my machine had been compromised. They were able to cut off network access to my machine. They could invalidate my octa sessions across all the applications so they could help secure my account and our company data. But in my local machine, I had MCP servers connected. I had API keys that I was using for certain things. That's the real we had to go through into all this. I was looking through my laptop saying, what did I connect it to? What services might I have? Some other credential not driven from the IDP that was at risk of being leaked. How do we go revoke that? How do we ensure that my system's safe? MCP today using OAuth, if something happens like that or you leave a company, an IT might revoke your single sign on through your IDP to those applications. You still have these access tokens, these refresh tokens, even in most cases, that give you standing access to these services. That means you might have access for days or weeks or even months. Many companies don't use things like SCEM, which allows you to revoke that access fully. And so that means that you have this lasting access problem that IT doesn't have any visibility over. And then, again, every time someone's on board into the team, they have to go through this whole thing where IT might better automatically set up the MCP servers you're using in something like cursor or Claude. But you still need to go through all this authentication and manage all these connections yourself. So obviously, this isn't great. So what are we doing about it? What's the solution to this? The solution is cross app access, otherwise known as XAA. XAA is basically a way in which the identity provider can act as a stand-in, a trust provider between applications. So let's say the example of IofCursor, that's my MCP client, Figma's the MCP server I want to connect to, and then Octa's the IDP that we use at our company for logging into things. So both cursor and Figma already have this trust relationship with Octa. Take it along to cursor, I go through Octa, it's along to Figma, I go through Octa. So both these applications know about workOS.octa.com. They know about me as a person that has access to these applications. What cross app access does, it helps bridge the gap between cursor and Figma. But providing a way for cursor to talk to Figma, they can both depend on that trust reliance on Octa. And they can get credentials issued without manual or human intervention. So let me show you a little bit what that looks like. So I'm going to flip over to my terminal and make it bigger and more visible. So here on the left on this tab, I have just like regular Claude Code set up. And if I check my MCP servers, I've connected the Figma server here. Obviously it needs authentication. I could go through that. It's going to present a consent screen. That's kind of the standard flow. In this window over here, we have a version of Claude Code that is XAA compatible, basically implemented XAA here. So the first thing I do just kind of show, since it's a sort of like a beta implementation of this, I can basically say I have configured inside of Claude Code. This connection to my Octa environment. And the first thing I'm going to do here is I'm going to log in. And so this is doing an Octa login. I'm going to log into my Octa environment. This is the thing you need to do one time in order to, if you're setting up Claude for the first time, you'd be logging into Octa. OK, that's all done now. And then now, if I start up Claude, and I look at my MCP servers, we'll notice here that Figma is automatically connected. Let me try and make that a little bit bigger. And so I didn't have to do anything. I didn't have to see a consent screen. Figma is automatically connected. And now with our Figma or a list of MCP servers, I can do all of that. I know that seems like magic. I didn't actually have to click anything. Did I actually do anything? Promise I did. Let me talk a little bit about what's actually happening behind the scenes. The whole point of this is you don't have to do anything. It appears as like it's automatic. But here's how it works. So in this situation, we're going to say of four systems. The client, which in that case was Claude Code I was using. The identity provider, which is Octa, the resource authorization server, which is in this case managed by Figma. But we're separating it from the resource server, which is the Figma API. If you're not familiar with MCP, you'll have the resource server like your MCP server. It will call out to a separate place to do authorization and issue tokens. So in the case, the first thing I did, I did that Octa login. So the user goes through SSO to the IDP. And that issues back an ID token and refresh token. So in this case, Claude holds onto those tokens. And it's able to use that in the next step to ask for what's called a IDJag token. So IDJag happens to be the name of the spec that all the technologies built off of. Sans4IdidityJWTAuthorizationGrant. It's very big mouthful. Effectively, it just means a token issued by an IDP that can be used across services to manage access. So the client goes back to the IDP and says, hey, I have this refresh token for Garrett. Would you please give me this IDJag token that will work with Figma? Octo basically knows about Claude. It knows about Figma. It can check, hey, is Garrett, remember, both of these applications? Or am I allowed to do this? Am I allowed to issue tokens for Claude on behalf of Figma? The answer is yes. Octo will send back this IDJag token to Claude Code. Then, Claude sends that to Figma. In this case, Figma's authorization server says, hey, I have this IDJag token for Garrett from the work OS Octo instance. Could you please validate this and provide me back a token? Figma, because it has this relationship with Octo, goes through verifies the IDJag. Once that's verified and correct, it is then able to issue this access token back to Claude Code. And at that point, step four here is the regular MCP offflow. So it just starts talking to the MCP server. It's using a regular access token. It's not a new type of credential. And then now I can talk to the MCP server Figma issue responses, and we're off to the races. A few things that are important here. Steps two and three here are totally invisible to the user. Once I've logged into the IDP, which I don't have to do that very often, that can be once a day. It's kind of up to the IT, your company's policies. Maybe that's once a day, maybe that's once a week. Once you've done that log in, you don't have to do that again. Steps two and three are done behind the scenes. And then step four is just the regular access token request that you're doing to the MCP server. The other thing around this is, in the case of this access token that's being issued, that could be very short lived. So most applications issue access tokens around five minutes. And so what happens is that token will expire after five minutes. But you don't need the human to do anything. You can basically rerun this IDJagflow plus the exchange and get a new access token as needed. And so as long as you're at the session, it's active. You can keep getting these IDJag tokens, exchange in for access tokens. And so you actually have a better security posture where it's something happens. And my access is removed for some reason, or my session is locked with Octa. Once that access token expires, I won't but a get back in. I won't better reconnect to that MCP server. And so I want to go a little bit through, what does this look like on the setup site? What does your IT admin need to do if you're running an MCP client? What do you need to do if you're running an MCP server? What do you need to do? On the IT side, it's actually pretty straightforward. You're already going to have a Claude Code or cursor Octa application created. You're already going to have the FidMAS SSO application created. Those will be existing things that your company already has. Inside of a system like Octa, there's this new kind of managed connections portal. Where you basically come in and say, which app do I want to grant the ability to request access to this other app? So in this case, we're saying cursor can request access to Figma. And that policy means that when cursor comes knocking and says, hey Octa, can I have an ID Jag token for Figma? Part of its request is which system does it want access to? Octa can verify that and say, yes, actually, cursor is allowed to request this access out of Figma. And why is she that token? So that's all you really have to do on the IT side. Once you've done that, everything else is as normal. The user must belong to both applications. You're doing the same management policy as you normally do. On the MCP client, so this would be your Claude Code, your cursor, if you're building your own MCP client, there's a handful of things you need to do. One, you need to have an SSO connection that's XA compatible. So in general, if you're supporting SSO in your application or your client, that's the standard fare. XA support is relatively new. So, Octa does support it with some caveats. They're working through those. We're working with other industry partners like Microsoft, for that have them support this as well. But you need that. And that customer's IDP connection would need to be XA compatible, enabled. Your client requests this ID Jag token from the ID ID identity provider. You get that token back. You need to make that exchange request to the MCP servers. You need to support that token flow. And then, once that's done, number four is your standard. Just talk to an MCP server. So nothing new there. We've built support as someone who we provide authentication services for our customers. We've built support for one, two, and three years. So we can handle your building. In MCP client, we can handle all of that flow. We're actually the way in which cursor and Anthropic are doing this because they use us for their SSO connections. On the MCP server side, which is probably more to most folks, as you might have an MCP server you aren't customers to use, there's also some stuff you need to support it on your side. The first is there's this new JWT bear type that you need to support. So this is basically announcing that you now support this ID Jag flow. And that you'll accept these kinds of tokens. Then obviously, MCP clients are going to send you those tokens. You usually accept them. And then you need to verify them. So there's a step where you go to the identity provider of the Octa URL and say, hey, is this a valid token? It's basically it's kind of assigned JWT, kind of like how you'd validate a JWT in any other context. You're doing the same thing here. And then last, which should be kind of the normal thing is issue the access token, right? So you've validated everything. Now you want to give them an access token. If you'd like to learn more about how this works, kind of treated this as a high level overview. Obviously there's a whole spec defining ID Jag and the specifics around how it should work. That's an exercise I leave to you. The reader, if you want to go explore the spec, I will say like, Claude is very good at explaining the spec, so that might be an easier way to get introduced to it without having to go read, you know, IETF, nomenclature. But here we have a blog post kind of outlining. All the details around ID Jag, how does it work? A lot more of the technical aspects of it if you're interested. So yeah, you can check that out to learn more. And with that, happy to answer any questions people have? Yeah. So this might solve. Yeah. So just to be honest, I'm going to repeat questions so that people on the recording can hear it. Question is this solves authentication, not authorization. Does this do anything to help with that? By default, no. So this is kind of just around the authentication bit. This is still, you know, you're logging into Figma as yourself, you know, so you're getting the permissions that you have with Figma. One of the things we're kind of talking about is like, OK, how do you extend this to be able to define like scope to access? So maybe, you know, octas saying, yes, I will grant this crop across that access. But there's caveats alongside the permissions I'm going to grant. That's not something that's like part of the spec today. But obviously, like something that's important that we need to consider. We don't have the same question, but the second book today. Yeah. How does the question, how does the MCP client know the app? It's requesting access for an octa. The answer is basically an audience URL. So you would use, in this case, it's like mcp.figma.com. You know, is the Figma's MCP server. That audience will be known inside of octa. And so your cursor will request to your octa and say, hey, here's the audience I'm looking for. That's configured inside of octa to say, like, the Figma app covers this audience. And then that's how it's checking the access request. So. What's your event up to use this? No, I don't think you can use it to hack scopes, because it's just the audience, which is kind of like a standard OAuth parlance. So yeah, that's the thing that like cursor knows the audience that it's trying to get based on the MCP server. Octa is configured to know for this app. That's the audience that it controls. And then obviously, you know, Figma knows its own audience and is checking the validity of the JWT with Octa. Cool. Yeah. Yeah, yeah, yeah. It's intro-supported. Microsoft hasn't yet added XAA support inside of Intra. That's something we're working with them on. If you have connections, push, because we want to get this adopted more broadly. Yeah, I kind of more generally today with Octa, the supported for OIDC-based connections, but they're going to support this for SAML-based connections as well. Kind of the spec defines that whatever you send to the IDP, it's either a refresh token ID token or a SAML assertion. So kind of just something that proves that you have in it, the user has a session in your app. That's the only part that cares about the type of SSL connection you have. But yeah, right now it's just Octa. Hopefully that will be more soon. OK, so they're. No, they don't support it yet. So can I follow up? Sure. OK. Sorry, this is to what part of the flow is this, or when cursor or clawed is talking to Microsoft here, is that for like single sign-on, or is that for talk- I'm seeing a sign-on. OK. Yeah. Yes. Yeah, I'd have to maybe, I could talk to you after we run this one. It's a little in the weeds. Yeah, I mean, if there's like an OIDC-based connection, then yeah, the scopes that the client is requesting need to match what the server will allow. And if there's a mismatch there, it's kind of different ways you can handle it. But like, you shouldn't grant obviously scopes that weren't allowed. So that might be what you can talk about it. And you can see that's the issue. Yeah. So the question was, is the intro to support DCR, so that creates issues? Yeah, that's kind of I think a general problem in the wild, is which clients or which servers support all the, as the MCP spec develops. So I would say most clients are to support DCR at this point, but obviously not everyone does. And there's not a lot you can really do if one doesn't support it. You have to go register. In the case of it's not DCR, you have to go pre-register that client. CIMD is the new standard that's superseeds DCR. It's a command, or I actually forgot what the CI stands for. It's like a meditated document that defines clients up front. So you don't have to create the clients every time. But that one has even less broad support in the ecosystem, because it's like three months old. But it is like a better experience. So yeah, there's still a little bit of catch up in the ecosystem to supporting the latest spec. Cool. Yeah. Great. Well, thanks, Evan, for your time. Have a great rest of the talk.
TL;DR
- Existing Microservice Communication Protocol (MCP) setups, relying on OAuth, force users through repetitive consent screens and provide limited visibility and control for IT administrators over application access and data security.
- Cross-App Access (XAA), powered by the IDJag specification, enables an Identity Provider (IDP) to act as a trusted intermediary, automating the secure exchange of credentials between MCP clients and servers.
- This solution eliminates the need for manual consent, centralizes access management for IT, and enhances security by allowing shorter-lived tokens and instant access revocation.
Takeaways
- Current MCP implementations using OAuth result in a poor user experience with "consent screens on top of consent screens" for each service connection.
- This traditional model lacks IT visibility into which MCP services and AI agents users are accessing, posing security risks regarding sensitive data and unapproved tools.
- Single Sign-On (SSO) systems are broken by traditional MCP, as applications don't inherently trust each other, forcing repeated authentication flows.
- Cross-App Access (XAA) (based on the IDJag specification) introduces the Identity Provider (IDP) as a trust provider to bridge communication between MCP clients and servers.
- Once a user logs into the IDP, the MCP client can automatically obtain credentials for connected MCP servers without further manual consent or interaction.
- XAA significantly improves security by allowing for very short-lived access tokens and enabling IT to centrally revoke access via the IDP, preventing lasting access issues if a user leaves or is compromised.
- For IT administrators, configuring XAA involves simply defining which MCP client applications are allowed to request access to specific MCP server applications within the IDP.
- MCP clients need an XAA-compatible SSO connection to the IDP, the ability to request IDJag tokens from the IDP, and to exchange these tokens for access tokens with MCP servers.
- MCP servers must support a new JWT bearer type, accept IDJag tokens, verify them with the IDP, and then issue standard access tokens to the client.
Vocabulary
MCP client — An application or tool (e.g., Cursor, Claude Code) that connects to and consumes services from various MCP servers.
MCP server — A service or application (e.g., Figma, Notion) that exposes resources to be accessed by MCP clients.
IDP (Identity Provider) — A system responsible for authenticating users and providing identity information to other services (e.g., Octa, Microsoft Intra).
OAuth — An open standard for access delegation, often used for authorization where users grant client applications access to resources on a server.
SSO (Single Sign-On) — An authentication scheme that allows a user to log in with a single IDP and gain access to multiple connected applications without re-authenticating.
Cross-App Access (XAA) — A solution that allows an IDP to mediate trust and automatically issue credentials between an MCP client and an MCP server, eliminating manual user consent.
IDJag (Identity JWT Authorization Grant) — The technical specification behind Cross-App Access, defining a token issued by an IDP that can be used across services to manage access.
Access Token — A credential issued by an authorization server to a client, granting access to specific protected resources.
Refresh Token — A credential used to obtain a new access token without requiring the user to re-authenticate, typically having a longer lifespan than an access token.
SCEM — A system or standard used by IT to fully revoke user access to applications, typically in scenarios like offboarding or security incidents.
DCR (Dynamic Client Registration) — A standard that allows OAuth clients to dynamically register themselves with an authorization server, rather than being pre-registered.
Transcript
All right, good morning, everybody. Thank you for coming to this talk. Hopefully your morning was eventful. I caught a little bit of the keynote and I wasn't able to catch all of it, but it was pretty good. My name's Gary Galo. Today I'm going to be talking about one login to rule the mall, or cross-up access for MCP, in case you haven't heard about that. Quick intro about myself. I run product at WorkOS. I've been building enterprise developer platforms for the past almost 15 years, originally in Microsoft Azure, then a Cloudflare for a long time, and now at WorkOS. If you haven't heard of WorkOS before, we make your app and also your agents enterprise ready. We power off for the likes of Anthropic, Cursor, OpenAI. So if you've ever logged into cursor, for example, whether that was with username password or an enterprise IDP, you've used WorkOS. Today I'm going to be talking about MCP and sign in through things like Anthropic and Cursor. But first, if you use MCP at all extensively, you know that it means consent screens on top of consent screens on top of consent screens. Who here uses MCP servers on the regular? OK, most of you. If you haven't kind of experienced this before, here is cursor, which I have set up. And if you want to use MCP servers with cursor, you add the menu, you have a little config file. And then in each one of these, if you want to use it, you have to connect. It'll pop up this window. You have this nice little consent screen that you're not going to read. You're just going to say OK, and you're going to get redirected back. And you need to do this for every single tool, which is frankly pretty annoying. And sometimes you have to do this again. You don't really know why. Sometimes you have to do this again. Sometimes it seems to forget that you've already done this. Yeah, and so this is like a thing you have to do every time you want to use these MCP servers. And that's not fun. But it's in the company with a lot of developers. It's not just one person's inconvenience. As a user, you might log into half-dozen or a dozen MCP servers. But when you combine that together across your team, you basically have dozens and dozens of people spending all this time managing all these consent screens, clicking these buttons. So without really caring why they have to do this. Now this is a relic of a lot of the technology that MCP decides to use. It uses OAuth as an underlying authentication layer. And so the way OAuth was kind of invented around was the thing of like, you know, these two systems don't trust each other. So you have to like provide this consent to say, yes, cursor can have access to my Figma account. Yes, cursor can have access to my notion account. But the reality is that's not really how things operate today. It's not how companies operate. We have a thing called single sign on. Most people are using it. If you have a company, you're logging in through something, an Octa or Microsoft Intra, one of these systems. And that's sort of that idea of one login signed into all those applications worked great. But MCP breaks this model. It sort of assumes that none of these apps know anything about each other. There's no way to know that you're the same person that you should have access to these systems. So you have to go through these flows over and over and over and over again. Now that is really annoying. And maybe that unto itself is a problem worth solving. But humans will tolerate a lot of annoyances if they get value out of it. The real problem comes in for the IT team. Like the people managing all these applications, MCP doesn't work the way that they want it to work. IT can't really tell what MCP service you may or not be using. You're connecting to these arbitrary things. You're not necessarily going through that IDP to connect to them, which is problematic. They basically can't determine which AI agents you can actually use. In theory, you can take any arbitrary MCP client. That might be a cursor, but you could be using a deep seek or some of these other tools that maybe your IT team doesn't want you to use. And you're granting access to these sensitive systems. You have lots of data and things like Figma or Notion that IT maybe doesn't want any AI agent to get access to. The other thing is actual access and security. I don't know how many people heard about the NPM Axios package getting popped about a week ago. Unfortunately, I was hit by that. I'm still not exactly sure what NPM package thing I used that had that dependency. But RIT team became aware of that problem. They were able to detect that my machine had been compromised. They were able to cut off network access to my machine. They could invalidate my octa sessions across all the applications so they could help secure my account and our company data. But in my local machine, I had MCP servers connected. I had API keys that I was using for certain things. That's the real we had to go through into all this. I was looking through my laptop saying, what did I connect it to? What services might I have? Some other credential not driven from the IDP that was at risk of being leaked. How do we go revoke that? How do we ensure that my system's safe? MCP today using OAuth, if something happens like that or you leave a company, an IT might revoke your single sign on through your IDP to those applications. You still have these access tokens, these refresh tokens, even in most cases, that give you standing access to these services. That means you might have access for days or weeks or even months. Many companies don't use things like SCEM, which allows you to revoke that access fully. And so that means that you have this lasting access problem that IT doesn't have any visibility over. And then, again, every time someone's on board into the team, they have to go through this whole thing where IT might better automatically set up the MCP servers you're using in something like cursor or Claude. But you still need to go through all this authentication and manage all these connections yourself. So obviously, this isn't great. So what are we doing about it? What's the solution to this? The solution is cross app access, otherwise known as XAA. XAA is basically a way in which the identity provider can act as a stand-in, a trust provider between applications. So let's say the example of IofCursor, that's my MCP client, Figma's the MCP server I want to connect to, and then Octa's the IDP that we use at our company for logging into things. So both cursor and Figma already have this trust relationship with Octa. Take it along to cursor, I go through Octa, it's along to Figma, I go through Octa. So both these applications know about workOS.octa.com. They know about me as a person that has access to these applications. What cross app access does, it helps bridge the gap between cursor and Figma. But providing a way for cursor to talk to Figma, they can both depend on that trust reliance on Octa. And they can get credentials issued without manual or human intervention. So let me show you a little bit what that looks like. So I'm going to flip over to my terminal and make it bigger and more visible. So here on the left on this tab, I have just like regular Claude Code set up. And if I check my MCP servers, I've connected the Figma server here. Obviously it needs authentication. I could go through that. It's going to present a consent screen. That's kind of the standard flow. In this window over here, we have a version of Claude Code that is XAA compatible, basically implemented XAA here. So the first thing I do just kind of show, since it's a sort of like a beta implementation of this, I can basically say I have configured inside of Claude Code. This connection to my Octa environment. And the first thing I'm going to do here is I'm going to log in. And so this is doing an Octa login. I'm going to log into my Octa environment. This is the thing you need to do one time in order to, if you're setting up Claude for the first time, you'd be logging into Octa. OK, that's all done now. And then now, if I start up Claude, and I look at my MCP servers, we'll notice here that Figma is automatically connected. Let me try and make that a little bit bigger. And so I didn't have to do anything. I didn't have to see a consent screen. Figma is automatically connected. And now with our Figma or a list of MCP servers, I can do all of that. I know that seems like magic. I didn't actually have to click anything. Did I actually do anything? Promise I did. Let me talk a little bit about what's actually happening behind the scenes. The whole point of this is you don't have to do anything. It appears as like it's automatic. But here's how it works. So in this situation, we're going to say of four systems. The client, which in that case was Claude Code I was using. The identity provider, which is Octa, the resource authorization server, which is in this case managed by Figma. But we're separating it from the resource server, which is the Figma API. If you're not familiar with MCP, you'll have the resource server like your MCP server. It will call out to a separate place to do authorization and issue tokens. So in the case, the first thing I did, I did that Octa login. So the user goes through SSO to the IDP. And that issues back an ID token and refresh token. So in this case, Claude holds onto those tokens. And it's able to use that in the next step to ask for what's called a IDJag token. So IDJag happens to be the name of the spec that all the technologies built off of. Sans4IdidityJWTAuthorizationGrant. It's very big mouthful. Effectively, it just means a token issued by an IDP that can be used across services to manage access. So the client goes back to the IDP and says, hey, I have this refresh token for Garrett. Would you please give me this IDJag token that will work with Figma? Octo basically knows about Claude. It knows about Figma. It can check, hey, is Garrett, remember, both of these applications? Or am I allowed to do this? Am I allowed to issue tokens for Claude on behalf of Figma? The answer is yes. Octo will send back this IDJag token to Claude Code. Then, Claude sends that to Figma. In this case, Figma's authorization server says, hey, I have this IDJag token for Garrett from the work OS Octo instance. Could you please validate this and provide me back a token? Figma, because it has this relationship with Octo, goes through verifies the IDJag. Once that's verified and correct, it is then able to issue this access token back to Claude Code. And at that point, step four here is the regular MCP offflow. So it just starts talking to the MCP server. It's using a regular access token. It's not a new type of credential. And then now I can talk to the MCP server Figma issue responses, and we're off to the races. A few things that are important here. Steps two and three here are totally invisible to the user. Once I've logged into the IDP, which I don't have to do that very often, that can be once a day. It's kind of up to the IT, your company's policies. Maybe that's once a day, maybe that's once a week. Once you've done that log in, you don't have to do that again. Steps two and three are done behind the scenes. And then step four is just the regular access token request that you're doing to the MCP server. The other thing around this is, in the case of this access token that's being issued, that could be very short lived. So most applications issue access tokens around five minutes. And so what happens is that token will expire after five minutes. But you don't need the human to do anything. You can basically rerun this IDJagflow plus the exchange and get a new access token as needed. And so as long as you're at the session, it's active. You can keep getting these IDJag tokens, exchange in for access tokens. And so you actually have a better security posture where it's something happens. And my access is removed for some reason, or my session is locked with Octa. Once that access token expires, I won't but a get back in. I won't better reconnect to that MCP server. And so I want to go a little bit through, what does this look like on the setup site? What does your IT admin need to do if you're running an MCP client? What do you need to do if you're running an MCP server? What do you need to do? On the IT side, it's actually pretty straightforward. You're already going to have a Claude Code or cursor Octa application created. You're already going to have the FidMAS SSO application created. Those will be existing things that your company already has. Inside of a system like Octa, there's this new kind of managed connections portal. Where you basically come in and say, which app do I want to grant the ability to request access to this other app? So in this case, we're saying cursor can request access to Figma. And that policy means that when cursor comes knocking and says, hey Octa, can I have an ID Jag token for Figma? Part of its request is which system does it want access to? Octa can verify that and say, yes, actually, cursor is allowed to request this access out of Figma. And why is she that token? So that's all you really have to do on the IT side. Once you've done that, everything else is as normal. The user must belong to both applications. You're doing the same management policy as you normally do. On the MCP client, so this would be your Claude Code, your cursor, if you're building your own MCP client, there's a handful of things you need to do. One, you need to have an SSO connection that's XA compatible. So in general, if you're supporting SSO in your application or your client, that's the standard fare. XA support is relatively new. So, Octa does support it with some caveats. They're working through those. We're working with other industry partners like Microsoft, for that have them support this as well. But you need that. And that customer's IDP connection would need to be XA compatible, enabled. Your client requests this ID Jag token from the ID ID identity provider. You get that token back. You need to make that exchange request to the MCP servers. You need to support that token flow. And then, once that's done, number four is your standard. Just talk to an MCP server. So nothing new there. We've built support as someone who we provide authentication services for our customers. We've built support for one, two, and three years. So we can handle your building. In MCP client, we can handle all of that flow. We're actually the way in which cursor and Anthropic are doing this because they use us for their SSO connections. On the MCP server side, which is probably more to most folks, as you might have an MCP server you aren't customers to use, there's also some stuff you need to support it on your side. The first is there's this new JWT bear type that you need to support. So this is basically announcing that you now support this ID Jag flow. And that you'll accept these kinds of tokens. Then obviously, MCP clients are going to send you those tokens. You usually accept them. And then you need to verify them. So there's a step where you go to the identity provider of the Octa URL and say, hey, is this a valid token? It's basically it's kind of assigned JWT, kind of like how you'd validate a JWT in any other context. You're doing the same thing here. And then last, which should be kind of the normal thing is issue the access token, right? So you've validated everything. Now you want to give them an access token. If you'd like to learn more about how this works, kind of treated this as a high level overview. Obviously there's a whole spec defining ID Jag and the specifics around how it should work. That's an exercise I leave to you. The reader, if you want to go explore the spec, I will say like, Claude is very good at explaining the spec, so that might be an easier way to get introduced to it without having to go read, you know, IETF, nomenclature. But here we have a blog post kind of outlining. All the details around ID Jag, how does it work? A lot more of the technical aspects of it if you're interested. So yeah, you can check that out to learn more. And with that, happy to answer any questions people have? Yeah. So this might solve. Yeah. So just to be honest, I'm going to repeat questions so that people on the recording can hear it. Question is this solves authentication, not authorization. Does this do anything to help with that? By default, no. So this is kind of just around the authentication bit. This is still, you know, you're logging into Figma as yourself, you know, so you're getting the permissions that you have with Figma. One of the things we're kind of talking about is like, OK, how do you extend this to be able to define like scope to access? So maybe, you know, octas saying, yes, I will grant this crop across that access. But there's caveats alongside the permissions I'm going to grant. That's not something that's like part of the spec today. But obviously, like something that's important that we need to consider. We don't have the same question, but the second book today. Yeah. How does the question, how does the MCP client know the app? It's requesting access for an octa. The answer is basically an audience URL. So you would use, in this case, it's like mcp.figma.com. You know, is the Figma's MCP server. That audience will be known inside of octa. And so your cursor will request to your octa and say, hey, here's the audience I'm looking for. That's configured inside of octa to say, like, the Figma app covers this audience. And then that's how it's checking the access request. So. What's your event up to use this? No, I don't think you can use it to hack scopes, because it's just the audience, which is kind of like a standard OAuth parlance. So yeah, that's the thing that like cursor knows the audience that it's trying to get based on the MCP server. Octa is configured to know for this app. That's the audience that it controls. And then obviously, you know, Figma knows its own audience and is checking the validity of the JWT with Octa. Cool. Yeah. Yeah, yeah, yeah. It's intro-supported. Microsoft hasn't yet added XAA support inside of Intra. That's something we're working with them on. If you have connections, push, because we want to get this adopted more broadly. Yeah, I kind of more generally today with Octa, the supported for OIDC-based connections, but they're going to support this for SAML-based connections as well. Kind of the spec defines that whatever you send to the IDP, it's either a refresh token ID token or a SAML assertion. So kind of just something that proves that you have in it, the user has a session in your app. That's the only part that cares about the type of SSL connection you have. But yeah, right now it's just Octa. Hopefully that will be more soon. OK, so they're. No, they don't support it yet. So can I follow up? Sure. OK. Sorry, this is to what part of the flow is this, or when cursor or clawed is talking to Microsoft here, is that for like single sign-on, or is that for talk- I'm seeing a sign-on. OK. Yeah. Yes. Yeah, I'd have to maybe, I could talk to you after we run this one. It's a little in the weeds. Yeah, I mean, if there's like an OIDC-based connection, then yeah, the scopes that the client is requesting need to match what the server will allow. And if there's a mismatch there, it's kind of different ways you can handle it. But like, you shouldn't grant obviously scopes that weren't allowed. So that might be what you can talk about it. And you can see that's the issue. Yeah. So the question was, is the intro to support DCR, so that creates issues? Yeah, that's kind of I think a general problem in the wild, is which clients or which servers support all the, as the MCP spec develops. So I would say most clients are to support DCR at this point, but obviously not everyone does. And there's not a lot you can really do if one doesn't support it. You have to go register. In the case of it's not DCR, you have to go pre-register that client. CIMD is the new standard that's superseeds DCR. It's a command, or I actually forgot what the CI stands for. It's like a meditated document that defines clients up front. So you don't have to create the clients every time. But that one has even less broad support in the ecosystem, because it's like three months old. But it is like a better experience. So yeah, there's still a little bit of catch up in the ecosystem to supporting the latest spec. Cool. Yeah. Great. Well, thanks, Evan, for your time. Have a great rest of the talk.