We recently added support for Enterprise-Managed Authorization in Atlassian Rovo MCP server using Cross-App Access (XAA) and the Identity Assertion JWT Authorization Grant (ID-JAG). In practical terms, this means an admin can centrally authorize MCP access for approved clients like Claude, and when users sign in, Rovo MCP can already be connected and ready to use, without sending users through a separate Atlassian OAuth consent screen. This feature is currently in private beta.
fun fact
In the old model, each user had to individually configure and connect a client to Atlassian through OAuth. In the new model, the enterprise IdP can broker that authorization decision up front, and Atlassian can still mint its own scoped access tokens for MCP after validating the enterprise-issued assertion.
Why we need an enterprise pattern
Traditional OAuth works well when a user is intentionally connecting one app to another. That pattern is familiar, explicit, and useful for individual app connections. Enterprise-managed MCP, however, introduces a different shape of problem: organizations need approved clients and resources to be available for many users, across many sanctioned connections, from day one.
That creates predictable problems:
- Smoother onboarding: users benefit when approved MCP connections are ready without each person repeating setup and consent steps for every connection they need.
- Consistent lifecycle management: enterprises can align access with centrally managed identity and app policies, including changes to user status or group membership.
- Policy expression: security teams need a way to define which approved clients can access which resources for which groups.
- Central visibility: enterprise-managed authorization makes it easier to understand and govern access decisions in one place.
For MCP specifically, the difference is especially visible. If a user logs in to an AI coding client and expects Atlassian tools to “just work,” enterprise-managed authorization lets that experience stay seamless while still giving admins the governance model they expect.
What XAA changes
XAA extends the trust relationship many enterprises already have with their identity provider. If both the requesting app and the resource app trust the same IdP for SSO and subject resolution, that IdP can broker cross-app API access as well.
The key building block is ID-JAG, a signed JWT assertion issued by the IdP for a specific downstream authorization server.
XAA keeps the resource authorization server in control of access tokens, while letting the enterprise IdP broker whether cross-app access should happen in the first place.
Tthe external IdP issues a short-lived identity-and-authorization assertion, and Atlassian OAuth validates it, applies local policy, resolves the user and client, and then issues an Atlassian token for Atlassian resources.
The flow we implemented
At a high level, the runtime sequence now looks like this:
- The user signs in to the MCP client (e.g. Claude) through the enterprise IdP.
- The client exchanges its identity assertion with the IdP for an
id-jag. - The client presents that ID-JAG to Atlassian OAuth using the JWT bearer grant.
- Atlassian OAuth validates the assertion, checks audience, client binding, expiry, and subject mapping, then mints a normal Atlassian access token.
- The client uses that Atlassian token against Rovo MCP.
So from the user’s perspective: they log in to Claude, Rovo MCP is there, and it works. From the protocol’s perspective: there is still strong separation between identity brokering and resource token issuance.
User → Enterprise IdP → ID-JAG → Atlassian OAuth → Atlassian access token → Rovo MCP +---------+ +---------------+ +---------------+ +----------+
| | | IdP | | Resource | | Resource |
| Client | | Authorization | | Authorization | | Server |
| | | Server | | Server | | |
+----+----+ +-------+-------+ +-------+-------+ +-----+----+
| | | |
| | | |
| -----------------> | | |
| 1 User SSO | | |
| | | |
| ID Token & | | |
| Refresh Token (Opt)| | |
| <- - - - - - - - - | | |
| | | |
| | | |
| | | |
| 2 Token Exchange | | |
| (Identity Assertion| | |
| or Refresh Token) | | |
| ----------------> | | |
| | | |
| ID-JAG | | |
| <- - - - - - - - | | |
| | | |
| | | |
| | | |
| 3 Present ID-JAG | | |
| -------------------+----------------> | |
| | | |
| Access Token | | |
| <- - - - - - - - - - - - - - - - - - -| |
| | | |
| | | |
| | | |
| 4 Resource Request with Access Token | |
| ------------------------------------------------------> |
| | | |
| | | |
| | | |What made the implementation interesting
This work didn’t involve just adding another grant type to be accepted. The exchange must be trusted, interoperable, and useful in a real enterprise deployment.
1. Supporting the right protocol boundary
The IETF draft defines a clear split:
- the IdP issues an ID-JAG using OAuth token exchange, and
- the resource authorization server accepts that ID-JAG via the JWT bearer grant.
That mapped well to our architecture. Atlassian OAuth acts as the Resource Authorization Server. It validates an incoming ID-JAG and issues Atlassian-native access tokens for Atlassian-protected resources.
We couldn’t have resource servers/product APIs directly trusting external bearer tokens. The model is to validate external assertions once, centrally, then mint Atlassian tokens with Atlassian-specific claims and policy boundaries.
2. Validating the ID-JAG correctly
An ID-JAG is not just “some JWT from an IdP.” For the exchange to be safe, the authorization server must validate several things together:
- Signature and issuer: the JWT must be signed by a trusted enterprise IdP (admin configured).
- Type: the header
typmust beoauth-id-jag+jwt. - Audience: the
audclaim must name Atlassian OAuth as the intended recipient. - Client continuity: the
client_idinside the ID-JAG must match the authenticated client redeeming it. - Freshness: normal JWT checks like
exp,iat, and unique token handling apply. - Resource and scope: requested access still has to make sense for the target Atlassian resource.
Note
One subtle but critical property of the spec is that the resource authorization server still applies local policy. An enterprise IdP can say “this request is allowed to be considered,” but Atlassian still decides what token to issue, whether to narrow scopes, and whether the user is valid for the target resource.
3. Resolving the user across trust domains
In the happy path, identity mapping sounds easy: take the subject claim and find the user. In real systems, it’s much more complex. The external subject could be:
- an IdP-local opaque user ID,
- an email address,
- a tenant-scoped identifier, or
- a SAML-derived subject representation, or
- something else
Our implementation requires that the id-jag contain a verified identity claim, so that we can reliably map this to an Atlassian account. This is one of the less glamorous parts of XAA, but it is where interoperability and integration challenges exist.
4. Making it admin-managed, not just spec-compliant
Protocol support alone would not solve the product problem. The value for enterprises comes from central administration.
For Rovo MCP, that means admins can manage which connectors and clients are allowed, and sanctioned users get the benefit without performing their own consent dance later. The operational model shifts from “every user self-authorizes” to “the organization governs access once.”
That is the piece that makes the end-user experience feel almost boring—in the best possible way.
What this looks like for users and admins
For users
They sign in to Claude. If their admin has already enabled the connector and policy allows it, Rovo MCP is available automatically. No second consent screen. No extra setup steps.
For admins
They can centrally manage who can use which MCP-connected clients and resources, instead of relying on every employee to individually authorize access.
That combination is what makes the feature compelling. Better UX without weaker controls is rare; this is one of those cases where both improve together.
Why this matters beyond MCP
XAA is especially timely for agentic products. AI clients need to cross trust boundaries constantly, and repeated user consent prompts do not fit that interaction model well. The enterprise still wants strong control, but the user expects the tooling across all of their work to be ready the moment they log in.
For Atlassian, this opens the door to a better model for externally hosted MCP clients and, more broadly, for any enterprise-approved client that needs access to Atlassian APIs on behalf of a user.
NOTE
The net result: enterprise-managed MCP access that feels seamless to end users, while preserving the authorization server controls and token semantics we need on the Atlassian side.
Closing thoughts
The nicest thing about this work is that, when it succeeds, users barely notice it. They log in, the connector is there and visible to the user, and everything feels pre-wired. It just works!
Under the hood, though, a lot is happening: token exchange between the IdP and Atlassian, typed JWT assertions, subject resolution, audience validation, client binding, and Atlassian-side token minting. XAA and ID-JAG let us take a interaction that is user driven and full of friction, and turn it into something enterprise-managed and largely invisible.
