One Login to Rule Them All: Cross-App Access for MCP

[upbeat music] 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. I wasn't able to catch all of it, but it was pretty good.

Um, my name's Garrett Galow. Today, I'm gonna be talking about One Login to Rule Them All, uh, or Cross-App Access for MCP, in case you haven't heard about that.

A quick intro about myself. Uh, I run Product at WorkOS. I've been building enterprise developer platforms for the past almost fifteen years. Uh, 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. Uh, 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/password or, like, an enterprise IdP, you've used WorkOS.

Um, today I'm gonna be talking about, uh, MCP and s- 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 wanna 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 wanna use it, you have to

connect. It'll pop up this window. You have this nice little consent screen that you're not gonna read. You're just gonna say okay, and you're gonna 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 wanna use, uh, these MCP servers. And, uh, that's not fun. But it's-- in, 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 the 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 unto 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's not-- doesn't work the way that they want it to work.

You know, IT can't really tell, like, what MCP service 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, um, 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 a-- 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 had I connected 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 say the example of, I have Cursor, that's my MCP client. Uh, Figma is the MCP server I wanna 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 gonna 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. It basically implemented XAA here. So, um, the first thing I do just to kinda 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 gonna log into my Okta environment. You know, this is a 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's 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 kinda seems like magic. I didn't actually have to click anything. Did I actually do anything? Promise I did. Let me kinda 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 onto those tokens, and it's able to use that in the next step to, uh, to ask for what's called a, uh, ID-JAG token.

So ID-JAG is, uh, happens to be the name of the spec that, that all this technology is built off of. 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 ID-JAG 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, 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 ID-JAG token to Claude Code.

Then Claude sends that to Figma, in this case, Figma's authorization server. Says, "Hey, I have this ID-JAG 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 ID-JAG. 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 could be very short-lived. So m- 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 ID-JAG 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 ID-JAG 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 wanna 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 gonna have a, like, Claude Code or Cursor Okta application created. You're already gonna have the Fid-- 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 wanna 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 ID-JAG 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 Cur-- uh, Okta does support it, but with some caveats. Um, they're working through those. We're working with other industry partners like Microsoft to have them support this as well.

But you need that, and that customer's, uh, IdP connection would need to be XAA compatib-- enabled. Uh, your client requests this ID-JAG token from the ID, uh, identity provider.

You get that token back. You need to make that exchange request to the MCP server, so 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 here, 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 your customers to use.

There's also some stuff you need to do to support it 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 ID-JAG 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 this kind of assigned JWT, kinda like how you'd validate a JWT in any other context. You're doing the same thing here. And then last, uh, which should be kinda the normal thing, is issue the access token, right?

So you validated everything, now you wanna give them an access token.

If you'd like to learn more about how this works, I'd, you know, kind of treated this as, like, a high-level overview. Obviously, like, there's a whole spec defining ID-JAG and the specifics around how it should work.

Uh, that's an exercise I leave to you, the reader, if you wanna 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 ID-JAG, how does it work, um, a lot more of the technical aspects of it if you're ever 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've got, like, different token scopes. Does that also solve the authorization bit as well?

Yeah. Uh, so just so y-- I'm gonna repeat questions so that people on the recording can hear it. The question is, this solves authentication, not authorization. Does this do anything to, to help with that?

Um, by default, no. Uh, so this is pu-- 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's saying, "Yes, I'm-- I will grant this cross- cross-app access, but there's caveats alongside, like, the permissions I'm gonna 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 gonna ask the same question, but a second part to it.

Yeah.

Um, how does the, uh, MCP client know which app to go for 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 and 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-

But would you be able to use that to hack scopes?

Um, no, I don't think you could use it to hack scopes 'cause 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, 'cause we wanna get this adopted more broadly. Um, yeah, kind of more generally, uh, today with Okta, this is supported for OIDC-based connections.

Um, they're, they're gonna 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 SSL 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 with-

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 talk-

For single sign-on.

Okay.

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

Yeah

... um, the resource, the resource and the scope have to match, otherwise Entra rejects it.

Yes.

And different protocols have-- need, need a set of different-

Yeah. I'd have to maybe-- And we can-- I can talk to you after on this one. It's a little in the weeds. Yeah, I mean, uh,

if it's like a OIDC-based connection, then yeah, the scopes that the client is requesting need to match-

Yeah

... what the server will allow.

Yeah.

And if there's a mismatch there, there's kinda different ways you can handle it.

Yeah.

But, like, you shouldn't grant obviously scopes that weren't, you know, allowed. Um, so that might be. We can talk about it. I can see, uh, if that's the issue.

Where, where Entra doesn't support DCR.

Mm. Yeah.

So you have to set up a proxy that now needs to be aware of which client is coming in to, um, tweak a few headers before sending it across to Entra.

I wonder if, like- [coughs] ...

Yeah. Uh, the question was Entra doesn't support DCR, so that creates issues. Yeah. That's, um,

uh, kinda 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, a command or... I actually forgot what the CI stands for. It's meta-- 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 'cause 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.

I'll, I'll catch up.

Cool. Yeah. Great. Well, thanks everyone for your time. Have a great rest of the conference. [clapping] [outro jingle]