One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS

Allright. Good morning, everybody. Thank you for coming to this talk; hopefully your morning was eventful. I caught a little bit of the keynote, I wasn't able to catch all of it, but it was pretty good. Um, my name is Garrett Galow.

Today I'm going to be talking about one login to rule them all, uh, or Cross-App Access for MCP, in case you haven't heard about that. Uh, quick intro about myself: I run product at WorkOS. I've been building enterprise developer platforms for the past almost 15 years, originally at Microsoft Azure, then at 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 auth for the likes of Anthropic, Cursor, OpenAI. So if you've ever logged into Cursor, for example, whether that was with username and password or, like, an enterprise IdP, you've used WorkOS.

Um, today I'm going to be talking about, uh, MCP and sign-in through things like Anthropic and Cursor. Um, but first, uh, if you've used 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? Okay. Most of you. Um, if you haven't kind of experienced this before, uh, here is, uh, Cursor, which I have set up. Uh, and if you want to use MCP servers with Cursor, you know, you add them in, you have the 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. Um, yeah, and so this is, like, a thing you have to do, uh, every time you want to use, uh, these MCP servers.

And, uh, that's not fun. But it's in a company with a lot of developers, it's not just, you know, one person's inconvenience. Uh, as a user, you might log into a half dozen or a dozen MCP servers. Um, 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, uh, 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, uh, authentication layer. And so, uh, the way OAuth was kind of invented around was this thing of, like, you don't tr 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. Um, but the reality is, that's not really how, uh, you know, things operate today. That's not how companies operate. Um, you know, we have a thing called Single Sign-On. Most people are using it.

If you have a company, you're logging in through something like an Okta or Microsoft Entra, one of these systems. Um, and that's sort of, you know, that idea of, like, one login, sign into all those applications worked great.

But MCP breaks this model,right? It sort of assumes that, uh, you know, none of these apps know anything about each other. There's no way to know that you're the same person, that, you know, you should have access to these systems.

And so you have to go through these flows over and over and over and over again. Now, that is really annoying. Um, and maybe that in and of itself is a problem worth solving, but, you know, humans will tolerate a lot of annoyances if they get value out of it.

The real problem comes in, um, for the IT team. Like, the people managing all these applications. Uh, MCP is not doesn't work the way that they want it to work. You know, IT can't really tell, like, what MCP servers you may or may not be using.

You're connecting to these arbitrary things. You're not necessarily going through that IdP to connect to them, um, which is problematic. They basically can't determine, uh, you know, which AI agents you can actually use,right? Uh, in theory, you can take any arbitrary MCP client.

You know, that might be a Cursor, but you could be using, uh, sort of like a DeepSeek or some of these other tools that maybe your IT team doesn't want you to use. And, um, you're granting access to these sensitive systems,right?

You know, you have lots of data in things like Figma or Notion that, you know, IT maybe doesn't want any, you know, any AI agent to get access to. The other thing is actual access and security. Um, I don't know how many people heard about the npm axios package getting popped about a week ago.

Uh, unfortunately, I was, uh, hit by that. I'm still not exactly sure what npm package thing I used that had that dependency. But, uh, you know, our IT team, you know, became aware of that problem. They were able to detect that, you know, my machine had been compromised.

They were able to cut off network access to my machine. They could invalidate my Okta sessions across all the applications so they could help secure, uh, you know, my, my account and our company data. But, you know, in my local machine, I had MCP servers connected.

I had, like, API keys that I was using for certain things. Like, that's the real we had to go through and do all this. You know, I was looking through my laptop, seeing, like, what did I connect it to?

What services might I have some sort of other credential not driven from the IdP that, you know, is at risk of being leaked? How do we go revoke that? How do we ensure that, you know, my system's safe?

Uh, MCP today using OAuth, you know, if something happens like that, or, you know, you leave a company and IT might revoke your, you know, 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, uh, days or weeks or even months. Um, you know, many companies don't use things like SCIM, which allows you to revoke that access fully. But, you know, and so that means that, uh, you have this, like, lasting access problem that IT doesn't have any visibility over.

And then, again, every time someone's onboarding to the team, they have to go through this whole thing where, uh, IT might be able to, like, automatically set up the MCP servers you're using in something like Cursor or Claude.

Um, but you still need to go through all this authentication, um, and manage all these connections yourself. So, um, obviously this isn't great. So what are we doing about it,right? 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 take the example of, I have Cursor. That's my MCP client. Uh, Figma is the MCP server I want to connect to.

And then Okta is the IdP that we use at our company for logging into things. So both Cursor and Figma already have this trust relationship with Okta,right? To log into Cursor, I go through Okta. To log into Figma, I go through Okta.

So both of these applications know about, you know, workos.okta.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 by providing a way for Cursor to talk to Figma.

They can both depend on that trust reliance on Okta, 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, uh, my terminal and make it bigger and more visible. So, uh, here on the left, on this tab, I have just, like, regular Claude code set up.

And, you know, if I check my MCP servers, uh, you know, I've connected the Figma server here. Obviously it needs authentication. I could go through that. You know, it's going to present a consent screen. Um, that's kind of the standard flow.

Uh, in this window over here, uh, we have a version of Claude code that is XAA compatible, basically implemented XAA here. So, um, the first thing I do is just kind of show, uh, since this is sort of like a, a beta implementation of this, um, I can basically say, like, I have configured inside of Claude code, um, this connection to my Okta environment.

And the first thing I'm going to do

here is

I'm going to log in. And so this is doing an Okta login. I'm going to log into my Okta environment. You know, this is the thing you need to do one time in order to, uh, if you were, you know, setting up Claude for the first time, you'd be logging into Okta.

Okay, that's all done now.

Um, 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 I didn't have to click anything.

I didn't have to see a consent screen. Uh, Figma is automatically connected. And now, you know, whether it's Figma or a list of MCP servers, I can do all of that. I know that kind of seems like magic.

I didn't actually have to click anything. Did I actually do anything? Promise I did. Let me kind of 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,right?

So it doesn't it appears as, like, it's sort of automatic. But, uh, here's how it works. So in this, uh, situation, we basically have four systems. The client, which in that case was Claude code I was using. The Identity Provider, which is Okta.

The Resource Authorization Server, uh, which is in this case managed by Figma, but we're separating it from the Resource Server, which is the Figma API. Um, if you're not familiar in MCP, you'll have the Resource Server, which is 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 Okta login,right? 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 on to those tokens, and it's able to use that in the next step to, uh, to ask for what's called a, uh, IDJag token. So IDJag is, uh, happens to be the name of the spec that, that all this technology is built off of.

It stands for Identity JWT Authorization Grant. It's a very big mouthful. Effectively, it just means a token issued by an IdP that can be used across services to, uh, 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?" Uh, Okta basically knows about Claude, knows about Figma. It can check, "Hey, is Garrett a member of both of these applications? Uh, are am I allowed to do this?

Is am I allowed to issue tokens for Claude on behalf of Figma?" The answer is yes. Okta will send back this IDJag token to Claude code. Then Claude sends that to Figma. In this case, Figma's authorization server. It says, "Hey, I have this IDJag token for Garrett from the WorkOS Okta instance.

Could you please validate this and provide me back a token?" Figma, because it has this relationship with Okta, 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, uh, step four here is the regular MCP auth flow. So it just starts talking to the MCP server. It's using a regular OAuth access token. It's not a new type of credential. And then, you know, now I can talk to the MCP server.

Figma will issue responses, and we're off to the races. Uh, a few things that are important here. Uh, steps two and three here are totally invisible to the user,right? Once I've logged into the IdP, which I don't have to do that very often, you know, that can be, you know, once a day.

It's kind of up to the IT, you know, your company's policies. Maybe that's once a day. Maybe that's once a week. Once you've done that login, you don't have to do that again. Steps two and three are done behind the scenes.

Uh, 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, uh, in the case of this access token that's being issued, uh, that can be very short-lived.

So most applications issue access tokens around five minutes. Um, 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 IDJag flow plus the exchange and get a new access token as needed.

And so as long as your SSO session is active, you can keep getting these IDJag tokens and exchanging them for access tokens. And so you actually have a better security posture where if something happens and, you know, my access is removed for some reason or my session is locked with Okta, once that access token expires, I won't be able to get back in.

I won't be able to reconnect to that MCP server.

And so I want to go a little bit through, um, you know, what does this look like on the setup side? Like, 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,right? Uh, you're already going to have a, like, Claude code or Cursor Okta application created. You're already going to have the Figma SSO application created,right?

Those will be existing things that your company already has. Inside of a system like Okta, there's this new kind of managed connections portal where you basically come in and say, "Hey, which app do I want to grant the ability to request access to this other app?"

So in this case, uh, we're saying Cursor can request access to Figma. Uh, and that policy means that when if Cursor comes knocking and says, "Hey, Okta, can I have an IDJag token for Figma?" Part of its request is which system does it want access to.

Okta can verify that and say, "Yes, actually, uh, Cursor is allowed to request this access out of Figma and will issue that token." So that's all, all you really have to do on the IT side. Once you've done that, everything else is as normal.

Like, you know, the user must belong to both applications. You're kind of doing the same kind of management policy as you normally do.

On the MCP client, so this would be your Claude code, your Cursor, or if you're building kind of your own MCP client, there's a handful of things you need to do. One, you need to have an SSO connection that's XAA compatible.

So, you know, in general, if you're supporting SSO in your application or your client, that's kind of the standard fare. Um, XAA support is relatively new. So Cursor, uh, Okta does support it, but with some caveats. Um, they're working through those.

We're working with other industry partners like Microsoft that have them support this as well. But you need that. And that customer's, uh, IdP connection would need to be XAA compatible enabled. Uh, your client requests this IDJag token from the Id, uh, Identity Provider.

You get that token back. You need to make that exchange request to the MCP servers. You need to, uh, support, uh, that token flow. And then once that's done, number four is your standard just talk to an MCP server.

So nothing new there. Uh, we've built support as someone who, you know, we provide authentication services for c for our customers. We've built support for one, two, and three years. So we can handle if you're building an MCP client, we can handle all of that flow.

Um, we're actually the way in which, you know, Cursor and Anthropic are doing this because they use us for their SSO connections. On the MCP server side, which is probably more relevant to most folks, is, like, you might be, you know, your company might have an MCP server you want customers to use.

There's also some stuff you need to do supported on your side. The first is there's this new, um, JWT bearer type that you need to support. Um, so this is basically, like, announcing that you now support, uh, this IDJag flow and that you'll accept these kinds of tokens.

Then obviously, like, MCP clients are going to send you those tokens. You need to accept them. Uh, and then you need to verify them. So there's a step where you go to the, uh, Identity Provider, the Okta URL, and say, like, "Hey, is this a valid token?"

It's basically it's kind of a signed JWT, kind of like how you'd validated JWT in any other context. You're doing the same thing here. And then last, uh, which should be kind of the normal thing, is issue the access token,right?

So you validated everything. Now you want to give them an access token.

If you'd like to learn more about how this works, I, you know, kind of treated this as, like, a high-level overview. Obviously, like, there's a whole spec defining IDJag and the specifics around how it should work. Uh, that's an exercise I leave to you, the reader, if you want to go explore the spec.

Um, 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, uh, IETF nomenclature. Um, but here we have a blog post kind of outlining all the details around IDJag, how does it work, um, a lot more of the technical aspects of it if you're very interested.

Um, so yeah, you can check that out to learn more. And with that, uh, happy to answer any questions people have. Yeah.

Uh, so this might, uh, this might solve the authentication problem, but does it also solve the authorization problem? Let's say for Figma, you call, like, different token scopes. Does that also solve the authorization bit as well?

Yeah. Uh, so just to be 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, to help with that? Um, by default, no.

Uh, so this is kind of just around the authentication bit. Um, this is still, you know, you're logging into Figma, uh, as yourself, you know, so you're getting the permissions that you have, uh, with Figma. Um, one of the things we're kind of talking about is, like, okay, how do you extend this to be able to, um, define, like, scoped access?

So maybe, uh, you know, Okta saying, "Yes, I, I will grant this cross-app access, but there's caveats alongside, like the permissions I'm going to grant." That's not something that's, like, part of the spec today, um, but obviously, like, something that's important that we need to consider.

Thank you. Uh, I'm going to ask the same question, but a second part to it.

Yeah.

Uh, how does the, uh, MCP client know which app to go for here inside Okta?

The question, how does the MCP client know the app it's requesting access for in Okta? Uh, the answer is basically like an audience URL. So you would use, um, in this case, it's like, you know, mcp.figma.com, you know, is the, the, uh, Figma's MCP server.

That audience will be known inside of Okta. And so, uh, your Cursor will request to your Okta instance, say, "Hey, here's the audience I'm looking for." Um, that's configured inside of Okta to say, like, the Figma app covers this audience, and then that's how it's checking the access request.

So.

So you don't have to use that to hack the scopes?

Um, no, I don't think you can use it to hack scopes because it's, it's just audience, which is kind of like a standard OAuth parlance. So, um, yeah, that's the thing that, like, uh, Cursor knows the audience that it's trying to get based on the MCP server.

Okta 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, and is checking, uh, you know, the validity of the JWT with, with Okta.

Cool. Yeah.

Do you support, uh, Azure?

Um.

Entra?

Yeah, yeah, yeah. It's Entra supported. Uh, Microsoft doesn't hasn't yet added XAA support inside of Entra. Um, that's something we're working with them on. If you have connections, push. Uh, because we want to get this adopted more broadly.

Um, yeah, kind of more generally, uh, today with Okta, this is supported for OIDC-based connections. Um, but they're, they're going to support this for SAML-based connections as well. Um, kind of the spec defines that you 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 an, you know, the user has a session in your app. Um, that's the only part that's cares about the type of SSO connection you have. But yeah,right now it's just Okta.

Hopefully that will be more soon.

Okay. So, so there is no Entra at the moment?

No, they don't support it yet.

Okay. So can I follow up?

Sure.

So with Microsoft, I ran into various client protocol fragmentation.

Okay.

Um, there was a resource parameter problem where Claude code sends the resource. Um, Entra validates, but it has to match the scope. Um, the way Codex does it is completely different. The way Claude desktop does it is not the same either.

Sorry, this is to what part of the flow is this or what when Cursor or Claude is talking to, uh, Microsoft here, is that for, like, Single Sign-On or is that for talking?

For Single Sign-On.

Okay.

So there's an RFC 9728. When, when does the initial discovery?

Yeah.

Uh, the resource, the resource and the scope have to match, otherwise Entra rejects it?

Yes.

And different protocols need, need instead of different?

Yeah, I'd have to maybe maybe we can I can talk to you after we run this one. It's a little in the weeds. Yeah, I mean, uh, if it'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, you know, allowed. Um, so that might be we can talk about it and can see, uh, if that's the issue.

Entra doesn't support VCR?

Mm. Yeah.

So instead of a proxy that now needs to be aware of which client is coming in to, uh, tweak a few headers before sending it across to Entra, I wonder if, like.

Yeah. Uh, the question was Entra doesn't support DCR, so that creates issues. Yeah, that's, um, uh, kind of I think a general problem in the wild is, you know, which clients and which servers support all the, you know, as the MCP spec develops.

Um, so I would say, like, most clients and servers support DCR at this point, but obviously not everyone does. And there's not a lot you can really do if, uh, you know, one doesn't support it. You have to, like, you know, go reg you know, in the case if it's not DCR, you have to go pre-register that client.

Um, you know, CIMD is like the new standard that kind of supersedes, uh, DCR. It's, um, uh, command or I actually forgot what the CI stands for. It's metadata. It's like a metadata document that defines clients up front.

So you don't have to create the clients every time. Um, but that one has even less broad support in the ecosystem because it's, you know, it's like three months old. Um, but it is like a better experience. So yeah, there's still a little bit of, um, catch-up in the ecosystem to, you know, uh, supporting, like, the latest spec.

Okay. I'll catch up.

Cool. Yeah.

Great. Well, thanks, Evan, for your time. Have a great rest of the conference.