Which grant type redeems an Okta ID-JAG for a Rovo MCP access token?

Question

We're connecting an internal AI agent to Rovo MCP via Okta Cross-App Access(XAA) / ID-JAG. Okta mints the ID-JAG correctly (audience`https://auth.atlassian.com`, resource `https://mcp.atlassian.com/v2/mcp`,`oauth-id-jag+jwt` type). We're stuck redeeming it for the Atlassian accesstoken Rovo MCP actually requires.

Both grant types that server's metadata advertises fail for this client:

- `jwt-bearer` → `invalid_client: grant_type is not enabled for client`- `token-exchange` → `invalid_request: subject_token_type is not supported`  (tried `id-jag`, `jwt`, `id_token`, `access_token`)

**Question:** which grant type is our client meant to use to redeem an ID-JAG for a Rovo MCP access token, and does our client need to be explicitly enabled/enrolled for it (e.g. the Enterprise-ManagedAuthorization for Rovo MCP beta)?

Sami Shaik · Answer

@Sawan Talwar ,

@Josh reading is right in general, and there is a specific, documented Atlassian path for exactly this, which answers both your questions.

The grant is JWT bearer. Atlassian's own engineering write-up of their XAA implementation describes the flow as: the client exchanges its identity assertion with the IdP for an ID-JAG, then presents the ID-JAG to Atlassian OAuth using the JWT bearer grant, and Atlassian issues a native access token for the MCP resource (How we brought enterprise-managed authorization to Rovo MCP with XAA and ID-JAG). Token exchange is the IdP-side step (how Okta mints the ID-JAG from your assertion), not the Atlassian-side redemption, which is why subject_token_type is rejected there whatever you pass.

Why jwt-bearer says "not enabled for client." Atlassian calls this feature enterprise-managed authentication, and it has to be switched on for the organisation before the authorization server will honour the grant: Atlassian Administration → Rovo → Rovo MCP server → Authentication tab → Allow enterprise managed authentication, then Edit URL to add the trusted identity provider URL (your Okta tenant) (configure enterprise-managed authentication). Until an org admin does that, the error you are seeing is the expected one.

Three values in your post differ from the documented ones, and any of them will fail validation even with the switch on:

* Audience. The Okta XAA resource app's Issuer URL is not the bare https://auth.atlassian.com; the doc gives a specific authorization-server URL under it (https://auth.atlassian.com/VCeDsk8ZHncYF1g234fKtc4lNipbBhu3). Your ID-JAG aud should match what Okta is configured with from that page.
* Audience / tenant ID. The Okta resource app also carries your cloudId (from https://<site>.atlassian.net/_edge/tenant_info) in the Audience/tenant field. Without it the assertion is not scoped to your tenant.
* Resource. The documented MCP URL for the enterprise-managed path is https://mcp.atlassian.com/v1/mcp/authv2, not /v2/mcp. The resource claim should match the endpoint you then call with the token.

Also, per the engineering post, the ID-JAG must carry a verified identity claim that maps to an Atlassian account; an assertion for a user who is not a managed account on that org will be refused after the grant itself is accepted.

On enrolment, the honest boundary. The support page is written for Claude as the MCP client and describes a "Managed authentication" option there. Your internal agent is a custom client, so it has to implement the MCP Enterprise-Managed Authorization extension itself (ID-JAG in, JWT bearer out). Whether Atlassian accepts any spec-compliant client once the org switch is on, or only clients it has registered, is not stated in the documentation I can find; the error text "not enabled for client" is consistent with either. Enable the org setting and align the three values first, because that removes the known causes; if the same error persists with everything matching, open a Support ticket referencing enterprise-managed authentication and ask that one question directly, with your client_id. One more thing to plan for: the page warns that MCP v2 scopes differ from v1, so if you restrict XAA scopes in Okta, add the v2 scopes or connections stop working.

Verified against the support page and the engineering post on 1 October 2026.

Josh · Answer

You are in a fairly new corner of the stack (Okta XAA / ID-JAG → Atlassian MCP token), so a few concrete notes:

* urn:ietf:params:oauth:grant-type:jwt-bearer failing with grant_type is not enabled for client usually means the Atlassian OAuth client (the one whose client_id you are using) was not created/enabled for that grant. Classic 3LO web clients often only expose authorization_code + refresh_token. You typically need an app / client that Atlassian has enabled for token exchange / JWT bearer for MCP.
* Token exchange failing on subject_token / audience often means the ID-JAG is being presented with the wrong subject_token_type, or the resource/audience on the JWT does not match what auth.atlassian.com expects for MCP (https://mcp.atlassian.com/...).

Practical path that teams are using today:

* Confirm the client is an Atlassian OAuth app registered for Rovo/MCP (not a generic Jira REST 3LO app).
* Redeem the ID-JAG only against the token endpoint and grant types listed in that server’s AS metadata — if jwt-bearer is advertised but rejected for your client_id, that is a client configuration issue on Atlassian’s side, not Okta minting.
* Open an Atlassian support / developer ticket with the client_id (not the secret), the exact error JSON, and that you are following Okta XAA → Atlassian MCP. This combination is still rolling out and often needs the right client feature flags.

I would not keep retrying jwt-bearer on a Jira REST client — it will keep returning invalid_client until the correct MCP-enabled client is used.