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

Channel: aiDotEngineer

Published at: 2026-04-28

YouTube video id: EmhRyw6xeT0

Source: https://www.youtube.com/watch?v=EmhRyw6xeT0

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
Gallo. 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. Uh, I run
product at WorkOS. I've been building
enterprise developer platforms for the
past almost 15 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 off for the likes of
Anthropic, Cursor, OpenAI. So, if you
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 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 and 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 okay.
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 the underlying, uh,
authentication layer. And so, uh, the
way OAuth was kind of invented around
was a thing of like, you don't trust,
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, 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.
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 going to get 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 saying
like, what am 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? All 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's the MCP server I want to
connect to.
And then Okta's 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 get logged 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
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 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 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 Octa 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 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
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 Octa 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. Octa 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 Octa instance.
Could you please validate this and
provide me back a token?"
Figma, because it has this relationship
with Octa, 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 off 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
could be, you know, once a day. It's
kind of up to the IT, you know, your
company's policies. Maybe that's once
today, 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,
most applications issue access tokens
around 5 minutes.
Um and so, what happens is that token
will expire after 5 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, 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
Octa, 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 Octa 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 Octa, 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
Octa, can I have an ID Jag token for
Figma?" part of its request is which
system is the one I want access to.
Octa can verify that and say, "Yes,
actually
uh Cursor is allowed to request this
access out of Figma."
And we'll 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 XA support is relatively new, so uh
Octa does support it, but with some
caveats.
Um they're working through those. We're
working with other industry partners
like Microsoft so that have them support
this as well.
But you need that, and that customer's
uh IDP connection will need to be XAA
compatible 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 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 Octa URL and say
like, "Hey, is this a valid token?" It's
basically this kind of a signed JWT.
Kind of 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 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 ID Jag 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 ID Jag,
how does it work, um a lot more of the
technical aspects of it if you're
interested. Um so, yeah, you can check
that out to learn more.
And with that, uh happy to answer any
questions people have.
Yeah.
Um
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 you know, I'm going to repeat
questions so 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 pure kind of just around
the authentication bit. Um this is
still, you know, you're logging into
Figma
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, Octa's saying, "Yes, I'm I
will grant this crop 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
It's the same question, but a second
part to it. Yeah. Um how does the
uh MCP client know which app to go for
inside Octa?
The question how does the MCP client
know the app it's requesting access for
in Octa? Uh the answer is based like an
audience URL. So, you would use um in
this case it's like, you know,
mcp.figma.com.
You know, it's the the
uh Figma's MCP server.
That audience will be known inside of
Octa. And so, uh your Cursor will
request to your Octa instance and say,
"Hey, here's the audience I'm looking
for."
Um 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 to prevent
you from using that to hack scopes?
Um no, I don't think you could use it to
hack scopes cuz 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.
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 and is
checking uh you know, the validity of
the JWT with with Octa.
Cool.
Yeah. Do you support uh Azure?
Um Intra. Yeah, yeah. Is Intra
supported? Uh
Microsoft doesn't hasn't yet added XAA
support inside of Intra. Um
that's something we're working with them
on. If you have connections, push uh cuz
we want to get this adopted more
broadly. Um yeah, I kind of more
generally uh
today with Octa, 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 intro at the
moment. No, they don't support it yet.
So,
can I follow up with Sure. So,
with Microsoft
I ran into various
client protocol fragmentation. Okay. Uh,
there was a resource parameter problem
where Cloud Code sends the resource. Uh,
Entra validates, but it has to match the
scope.
Um,
the way
Codex does it is completely different.
The way Cloud Desktop does it is not the
same either. Sorry, this is to
what part of the flow is this or what
when Cursor or Cloud is talking to
uh, Microsoft here, is that for like
single sign-on or is that for talk
>> Single sign-on. Okay.
So, there's an RFC 9728.
What what what does the initial
discovery?
Yeah. Uh,
the resource and the resource and the
scope have to match, otherwise Entra
rejects it.
Yes.
And different protocols have need a set
of different
Yeah, I would 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 a 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, there'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. Yeah, Entra
doesn't
support DCR.
Mm, yeah. set up a proxy come back. Now
needs to be aware of which client is
coming in to
uh,
tweak a few headers before sending it
across the network. 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 register, 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's 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 cuz
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 catch up. Cool, yeah.
Great. Well, thanks everyone for your
time. Have a great rest of the
conference.