Talk by Garrett Galow (WorkOS) on Cross-App Access for MCP: using a three-way trust between the MCP client, MCP server, and the organization's Identity Provider, the Identity Assertion Authorization Grant flow turns a single SSO login into access tokens across every MCP server, eliminating repeated OAuth consent screens and token lifecycles. The talk also discusses how this pattern extends to agent identity beyond MCP. # Video Identity Observations — Cross-App Access for MCP (Garrett Galow, WorkOS) ## Explicit Self-Description Evidence - **Creator identity and role**: The speaker introduces himself directly: *"my name's Garrett Gallo... I run product at WorkOS."* - **Company self-description**: WorkOS is described as: *"we make your app and also your agents enterprise ready. We power auth for the likes of Anthropic, Cursor, OpenAI."* - **Speaker's claimed background**: *"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."* - **Company's role in the demonstrated technology**: *"we've built support for one, two, and three here... we're actually the way in which Cursor and Anthropic are doing this because they use us for their SSO connections."* ## Claimed Scope of the Channel/Presentation - **Topic scope**: Technical talk on **cross-app access (XAA)** for MCP, built on the **Identity JWT Authorization Grant (ID-JAG)** spec. - **Stated format and depth**: *"I kind of treated this as like a high-level overview... there's a whole spec defining ID Jag... that's an exercise I leave to you, the reader."* - **Cross-referenced resources**: A blog post is mentioned: *"we have a blog post kind of outlining all the details around ID Jag."* - **Interactive format**: The talk ends with audience Q&A, indicating a live conference presentation with technical attendees. ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Live demonstration**: The speaker shows a working beta implementation in a terminal — Claude Code with and without XAA support — including a live Okta login and automatic Figma MCP connection: *"Figma is automatically connected... I didn't have to click anything."* - **Diagrams/step explanations**: A four-system flow (client, IDP, resource authorization server, resource server) is walked through step by step. - **Current-events references**: References a recent security incident: *"I don't know how many people heard about the NPM Axios package getting popped about a week ago."* - **Ecosystem status reporting**: Frank statements about partner adoption gaps: *"Microsoft hasn't yet added XAA support inside of Entra... right now it's just Okta. Hopefully, that will be more soon."* ## Intended Audience (As Demonstrated) - **Developer-conference attendees**: Opening address — *"Good morning everybody. Thank you for coming to this talk"* — and closing — *"Have a great rest of the conference."* - **MCP-active technical audience**: *"Who here uses MCP servers on the regular? Okay, most of you."* - **Multiple audience segments addressed explicitly in content**: - **IT administrators**: "what does your IT admin need to do?" - **MCP client builders**: "if you're building kind of your own MCP client, there's a handful of things you need to do" - **MCP server builders**: "which is probably more relevant to most folks" - **Sophisticated Q&A audience**: Audience questions cover RFC 9728, DCR (dynamic client registration), CIMD, scope validation in Entra — indicating identity/OAuth practitioner-level attendees. ## Tone and Positioning - **Practitioner-to-practitioner tone**: Casual, first-person war stories (*"Unfortunately, I was hit by that... I was looking through my laptop saying like, what am I connected to?"*). - **Vendor-anchored but standards-framed**: The talk centers on WorkOS's implementation while deferring to the IETF ID-JAG spec and promoting ecosystem adoption (*"we want to get this adopted more broadly"*). - **Honest limitation disclosure**: Acknowledges authorization/scoping is unsolved (*"by default, no... that's not something that's part of the spec today"*) and that some IdPs don't yet support XAA. # Delivery Observation: Garrett Galow — "One Login to Rule Them All: Cross-App Access for MCP" ## Overall Tone and Register - **Conversational and informal** throughout: heavy use of filler words ("uh," "um," "you know") and casual asides. - **Humor and relatability** used to connect with the audience: > "You have this nice little consent screen that you're not going to read. You're just going to say okay." > "I know that kind of seems like magic. I didn't actually have to click anything. Did I actually do anything? Promise I did." - **Audience-aware opener** referencing the shared event context: > "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." ## Teaching Habits and Structure - **Problem → solution → mechanics → setup** structure: he spends the first half of the talk establishing pain points before introducing cross-app access (XAA): > "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." - **Concrete, recurring example triad**: Cursor (client), Figma (server), Okta (IDP) used consistently from the first explanation through the demo and Q&A. - **Live demo with terminal walkthrough**, with deliberate transparency about setup: > "So, I'm going to flip over to, uh, my terminal and make it bigger and more visible." > "since this is sort of like a a beta implementation of this" - **Numbered-step explanation** of the token flow ("step four here is the regular MCP off flow"), then reassurance about which steps are invisible to users: > "Uh steps two and three here are totally invisible to the user, right?" - **Personal anecdote as evidence** for the security risk section: > "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." - **Role-based framing for setup guidance**: separate sections for IT admins, MCP client builders, and MCP server builders ("On the IT side, it's actually pretty straightforward..."). ## Recurring Vocabulary and Phrases - **"You know"** as a constant verbal connector — appears dozens of times across the transcript. - **"Right?"** used as a check-in tag when asserting shared understanding: > "But MCP breaks this model, right?" > "both Cursor and Figma already have this trust relationship with Okta, right?" - **"Hey, ..."** as a recurring device when voicing system-to-system requests, personifying the protocol: > "The client goes back to the IDP and says, 'Hey, I have this refresh token for Garrett.'" > "Says, 'Hey, I have this ID Jag token for Garrett from the WorkOS Octa instance.'" > "Come in and say, 'Hey, which app do I want to grant the ability to request access to this other app?'" - **"So, yeah" / "Uh, so"** as transition phrases between sections. - Colloquial phrasing for technical failures: "getting popped," "we're off to the races," "in the weeds." ## Audience Interaction Patterns - **Show-of-hands question** to calibrate audience knowledge: > "Who here uses MCP servers on the regular? Okay, most of you." - **Repeating audience questions aloud for the recording** — an explicit, stated practice: > "just so you know, I'm going to repeat questions so people on the recording can hear it." (He does this consistently in the first two Q&A answers, though some later questions appear only as fragments in the transcript.) - **Direct honesty about limits of knowledge**, deferring detail rather than bluffing: > "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." > "I actually forgot what the CI stands for." ## Marketing and Self-Presentation - Brief, factual company introduction tied to recognizable names rather than a sales pitch: > "we power off for the likes of Anthropic, Cursor, OpenAI. So, if you ever logged into Cursor for example... you've used WorkOS." - One later mention of WorkOS product capability, framed as helpfulness: > "we've built support for one, two, and three here." - Encourages audience to push vendors toward adoption: > "If you have connections, push uh cuz we want to get this adopted more broadly." ## Uncertainty Notes - The fillers ("uh," "um") are pervasive and stable across the talk; this is clearly characteristic, not a one-off. - Whether the "Hey, ..." personification is a stable teaching habit or specific to this flow explanation is supported by roughly four instances — reasonably consistent, but drawn from one technical section. - Q&A delivery differs from the prepared talk: shorter answers, more hedging ("maybe," "kind of"), and occasional admissions of not knowing — observable but based on a limited Q&A sample. # Position Record: Cross-App Access for MCP — Garrett Galow, WorkOS ## Speaker - **Garrett Galow**, Head of Product at **WorkOS**; prior roles at Microsoft Azure and Cloudflare (~15 years building enterprise developer platforms). ## Problem Framing (Stated Positions) ### MCP's consent-screen burden - MCP relies on **OAuth** as its authentication layer, which assumes apps don't trust each other — producing "consent screens on top of consent screens." - Users may connect a half-dozen to a dozen MCP servers; at company scale this becomes dozens of people "managing all these consent screens... without really caring why." - Sessions sometimes expire inexplicably: *"Sometimes it seems to forget that you've already done this."* ### MCP breaks single sign-on - Companies already have **SSO** via Okta/Entra; MCP's model assumes no app knows about another, forcing repeated consent flows. ### IT/security concerns (framed by Galow as the "real problem") - IT cannot see which MCP servers employees use; arbitrary MCP clients (e.g., "DeepSeek or some of these other tools") may access sensitive data in Figma/Notion. - Cited personal anecdote: the **NPM Axios compromise** (~a week before the talk) hit his machine. IT detected it, cut network access, invalidated Okta sessions — but his locally connected MCP servers and API keys were outside IDP control and had to be manually audited and revoked. - Standing access risk: OAuth access/refresh tokens can persist for **days, weeks, or months** after SSO revocation or offboarding; many companies don't use **SCIM**. ## Proposed Solution: Cross-App Access (XAA) ### Core idea - The **identity provider acts as a trust broker** between MCP client and MCP server, both of which already trust the IDP. Credentials are issued "without manual or human intervention." ### Flow (as demonstrated with Claude Code + Figma + Okta) Four systems: client, IDP, resource authorization server, resource server. 1. User logs into IDP via SSO → receives ID + refresh tokens (held by client). 2. Client requests an **ID-JAG token** (Identity JWT Authorization Grant) from the IDP, naming the target audience; IDP checks membership and cross-app policy. 3. Client exchanges the ID-JAG token at the target's authorization server, which validates it with the IDP and returns a standard OAuth access token. 4. Normal MCP/OAuth communication with the MCP server — *"It's not a new type of credential."* ### Security claims - Steps 2–3 are invisible to the user after the (infrequent) IDP login. - Access tokens can be **short-lived (~5 minutes)** and silently renewed via ID-JAG re-exchange while the SSO session is valid — improving revocation posture. ### Setup requirements (per Galow) - **IT**: configure cross-app access policy in the IDP (e.g., "Cursor can request access to Figma"); user must belong to both apps. - **MCP client**: XAA-compatible SSO connection; request ID-JAG; make exchange request; standard MCP communication. WorkOS has built steps 1–3 and powers Cursor and Anthropic's SSO. - **MCP server**: support new JWT bearer type; accept and verify ID-JAG tokens against the IDP; issue access tokens. ## Qualifications and Unresolved Tensions - **Authorization not solved**: Asked whether XAA handles scoped authorization, Galow answered **"by default, no"** — it is purely authentication; users get their existing Figma permissions. Scoped/caveated grants are "something we're kind of talking about" but **not in the spec today**. - **IDP support limited**: Only **Okta** supports XAA today, and only for **OIDC** connections; SAML support is planned. **Microsoft Entra does not yet support XAA** ("we're working with them on it"). - **Ecosystem fragmentation** (audience Q&A): - Entra does not support **DCR** (dynamic client registration); audience member noted client protocol fragmentation — different clients (Cursor, Codex, Claude Desktop) handle resource/scope parameters differently, and Entra requires resource to match scope. - Galow acknowledged this is "a general problem in the wild," deferring detailed discussion to after the talk. - **CIMD** mentioned as a newer standard superseding DCR, but with "even less broad support... it's like three months old." - Audience question about "hacking scopes" via audience URLs: Galow said no — audience is standard OAuth parlance; Okta and Figma each validate it. - ID-JAG spec details deferred: Galow recommended the WorkOS blog post and noted "Claude is very good at explaining the spec" versus reading IETF documents. # Speaker Attribution Record ## Video - **Title:** One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS - **Video ID:** `01a15ca9-8635-7039-88fe-2a9a83d49f0a` ## Speakers ### Garrett Galow — Creator / Presenter - Sole primary speaker; introduces himself: **"my name's Garrett Gallo"** (transcript also renders "Gallo" once). - Self-described role: **runs product at WorkOS**, ~15 years building enterprise developer platforms (Microsoft Azure, Cloudflare, now WorkOS). - Delivers the full talk, demonstration, and answers audience questions. - Speaker repeats audience questions aloud "so people on the recording can hear it." ### Audience Members — Guests / Q&A Participants (unidentified) - Multiple unnamed audience questioners during Q&A: - Asks whether XAA solves **authorization** vs. authentication. - Asks how the MCP client knows which app to request in Okta. - Asks about "hacking scopes" via audience. - Asks whether **Microsoft Entra** is supported. - Extended exchange on Entra client protocol fragmentation, **RFC 9728**, resource/scope matching, **DCR** support, and a **proxy workaround**. ### Mentioned entities (non-speaking) - Okta, Microsoft Entra, Cursor, Anthropic, OpenAI, Cloudflare, Figma, Notion, Claude (Code/Desktop), Codex, DeepSeek, NPM/Axios, IETF — referenced only, not speakers. ## Promotional Segments - **Flagged:** WorkOS promotional framing in the introduction: *"we make your app and also your agents enterprise ready. We power off for the likes of Anthropic, Cursor, OpenAI."* - **Flagged:** Mid-talk promotion: WorkOS *"built support for one, two, and three"* of the client-side XAA steps; *"we're actually the way in which Cursor and Anthropic are doing this."* - **Flagged (soft):** Closing pointer to a WorkOS **blog post** on ID-JAG as further reading. ## Referenced Sources & Third-Party Claims - **ID-JAG spec** (Identity JWT Authorization Grant) — cited as the underlying specification (IETF); audience directed to read the spec. - **RFC 9728** — raised by an audience member regarding resource discovery. - **OAuth, SSO/IdP, SCIM, CIMD, DCR** — referenced standards/protocols. - **NPM Axios package compromise** — third-party incident claim (~"about a week ago"); speaker states he was personally affected. - Live demo: Claude Code with an Okta environment configured; a "beta implementation" of XAA. - Okta XAA support claimed for **OIDC-based connections**, with SAML "coming"; Entra claimed **not yet supported**. ## Comment Availability - Not stated in transcript or metadata; **unknown**. ## Uncertainty Notes - Speaker's surname appears as both "Gallo" and "Galow" in the transcript; video title says **"Garrett Galow."** - Audience speakers are entirely unidentified; role inferred from Q&A context. - No curated metadata supplied beyond the title; all provenance above derives from the 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. 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.