Enterprise Managed Auth for connectors changedconnectors/building/enterprise-managed-auth
Nearest release: v2.1.283, published under an hour after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 25 Sep 2026 18:00 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 25 Sep 2026 18:07 UTC.
Upstream edited
Recorded here
Lines+47added
Lines−72removed
From line
6
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
## Understand how Enterprise Managed Auth works ### Enterprise Managed Auth with lazy authentication ### Access token lifetime ## Test your implementation ### Test with the cross-app access playground ## Support customer administrators ### Admin settings in your product ### Provide setup documentation ### Okta Integration Network apps ## How it works ## With lazy authentication ## Access token lifetime ## Testing your implementation ### Testing with the cross-app access playground ## Admin settings in your product ## Provide setup documentation ## Okta Integration Network apps
The whole hunk
from line 6, old and new numbered
/
from line 6
66 Enterprise Managed Auth is available on Claude Team and Enterprise plans. MCP server developers and identity provider vendors can [register interest](https://docs.google.com/forms/d/e/1FAIpQLSf1goHGNDVFK7rncYuh6wnRpWSy7eGOcgL1i8uw3oyKFO9UUA/viewform) in supporting this flow.
77</Note>
88
9Enterprise Managed Auth (EMA) lets a user connect to your MCP server silently, using the single sign-on session they already have with their organization. Instead of showing each user an OAuth consent screen, Claude presents your authorization server with an **identity assertion**: a signed JSON Web Token (JWT), issued by the customer's identity provider, that vouches for the user's identity.
9Enterprise Managed Auth (EMA) lets a user connect to your MCP server silently, using the single sign-on session they already have with their organization. Instead of showing each user an OAuth consent screen, Claude presents your authorization server with an identity assertion: a signed JSON Web Token (JWT), issued by the customer's identity provider, that vouches for the user's identity.
1010
11Your authorization server validates the assertion and returns an access token in a single back-channel request. There is no browser redirect and no per-connector consent page. From the user's point of view, the connector is simply available as soon as their administrator enables it.
11Your authorization server validates the assertion and returns an access token in a single back-channel request. There is no browser redirect and no per-connector consent page. From the user's point of view, the connector is available as soon as their administrator enables it.
1212
13This flow is defined by the [MCP enterprise managed authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) and is built on the standard [JWT bearer authorization grant (RFC 7523)](https://datatracker.ietf.org/doc/html/rfc7523). The assertion profile follows the [Identity Assertion JWT Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).
13This page is for connector developers who need their authorization server to accept Enterprise Managed Auth. The customer's administrator handles identity provider setup and Claude admin console configuration, so those aren't covered here. The page walks through [how the exchange works](#understand-how-enterprise-managed-auth-works), the [prerequisites](#prerequisites), [what your authorization server must support](#authorization-server-requirements), [how to test](#test-your-implementation), and [what to give customer administrators](#support-customer-administrators).
1414
15<Note>
16 This page is for connector developers who need their authorization server to accept Enterprise Managed Auth. Identity provider setup and Claude admin console configuration are handled by the customer's administrator.
17</Note>
15## Understand how Enterprise Managed Auth works
1816
19## How it works
17When a user whose organization has Enterprise Managed Auth configured invokes your connector, Claude obtains a signed identity assertion for that user and exchanges it directly at your token endpoint for an access token. The user never sees a browser redirect or a consent screen, and your MCP server receives the same kind of bearer token it would after the interactive OAuth flow. The diagram shows the exchange between Claude, your authorization server, and your MCP server.
2018
21When a user whose organization has Enterprise Managed Auth configured invokes your connector, Claude obtains a signed identity assertion for that user and exchanges it directly at your token endpoint for an access token. The user never sees a browser redirect or a consent screen, and your MCP server receives the same kind of bearer token it would after the interactive OAuth flow.
19<img className="block dark:hidden" src="https://mintcdn.com/claude-ai/-njlLvrWxFCRdJVz/images/connectors/enterprise-managed-auth-exchange.svg?fit=max&auto=format&n=-njlLvrWxFCRdJVz&q=85&s=2bdd0b680bda337b37632516b8dc5e84" alt="Sequence diagram with three participants: Claude, your authorization server, and your MCP server. The user is already signed in to Claude through their organization's single sign-on. 1, Claude sends POST /token to your authorization server with the jwt-bearer grant and the signed JWT assertion. 2, your authorization server fetches the issuer's JWKS and verifies the signature. 3, it validates iss, aud, exp, sub, and client_id. 4, it returns an access_token to Claude. 5, Claude sends the tool call to your MCP server with the Bearer access_token. 6, your MCP server returns the tool result to Claude. Requests are solid arrows and responses are dashed arrows." width="1000" height="560" data-path="images/connectors/enterprise-managed-auth-exchange.svg" />
2220
23```mermaid theme={null}
24sequenceDiagram
25 autonumber
26 participant Claude
27 participant AS as Your authorization server
28 participant MCP as Your MCP server
21<img className="hidden dark:block" src="https://mintcdn.com/claude-ai/-njlLvrWxFCRdJVz/images/connectors/enterprise-managed-auth-exchange-dark.svg?fit=max&auto=format&n=-njlLvrWxFCRdJVz&q=85&s=5b8c6c81ef448cfb08deb05f0d02b712" alt="Sequence diagram with three participants: Claude, your authorization server, and your MCP server. The user is already signed in to Claude through their organization's single sign-on. 1, Claude sends POST /token to your authorization server with the jwt-bearer grant and the signed JWT assertion. 2, your authorization server fetches the issuer's JWKS and verifies the signature. 3, it validates iss, aud, exp, sub, and client_id. 4, it returns an access_token to Claude. 5, Claude sends the tool call to your MCP server with the Bearer access_token. 6, your MCP server returns the tool result to Claude. Requests are solid arrows and responses are dashed arrows." width="1000" height="560" data-path="images/connectors/enterprise-managed-auth-exchange-dark.svg" />
2922
30 Note over Claude: User is signed in to Claude through their organization's SSO
31 Claude->>AS: POST /token (grant_type=jwt-bearer, assertion=signed JWT)
32 AS->>AS: Fetch issuer JWKS and verify signature
33 AS->>AS: Validate iss, aud, exp, sub, and client_id
34 AS-->>Claude: access_token
35 Claude->>MCP: Tool call with Bearer access_token
36 MCP-->>Claude: Tool result
37```
38
3923Two parties are involved in this exchange: the customer's identity provider signs the assertion, and your authorization server verifies it and issues the access token. Both roles are often served by commercial identity platforms, so the distinction here is about which tenant plays which role rather than about product type. The identity provider publishes its signing keys as a JSON Web Key Set, and your authorization server fetches that key set to verify each assertion.
4024
41## With lazy authentication
25The Enterprise Managed Auth flow is defined by the [MCP enterprise managed authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) and is built on the standard [JWT bearer authorization grant (RFC 7523)](https://datatracker.ietf.org/doc/html/rfc7523). The assertion profile follows the [Identity Assertion JWT Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).
4226
43Enterprise Managed Auth also works with [lazy authentication](./lazy-authentication). When your server returns `401 Unauthorized` for a protected tool call, Claude normally shows the inline **Connect** card and runs the interactive OAuth flow. If the user's organization has Enterprise Managed Auth configured for your connector, Claude runs the silent JWT bearer exchange instead and retries the tool call without showing a prompt.
27### Enterprise Managed Auth with lazy authentication
4428
45Your MCP server returns the same `401` with a `WWW-Authenticate` header as described in the [lazy authentication guide](./lazy-authentication#return-401-not-a-tool-error). Your authorization server must still meet the [requirements below](#authorization-server-requirements).
29Enterprise Managed Auth also works with [lazy authentication](/docs/connectors/building/lazy-authentication). When your server returns `401 Unauthorized` for a protected tool call, Claude normally shows the inline **Connect** card and runs the interactive OAuth flow. If the user's organization has Enterprise Managed Auth configured for your connector, Claude runs the silent JWT bearer exchange instead and retries the tool call without showing a prompt.
4630
47A fully authless server never returns `401`, so there is no point at which Claude can exchange an assertion. Enterprise Managed Auth does not apply to authless servers.
31Your MCP server returns the same `401` with a `WWW-Authenticate` header as described in the [lazy authentication guide](/docs/connectors/building/lazy-authentication#answer-a-protected-call-with-401-before-the-mcp-sdk-runs). Your authorization server must still meet the [authorization server requirements](#authorization-server-requirements).
4832
33Enterprise Managed Auth doesn't apply to authless servers. A fully authless server never returns `401`, so there is no point at which Claude can exchange an assertion.
34
4935## Prerequisites
5036
51Before adding Enterprise Managed Auth, make sure the following are already in place.
37Before adding Enterprise Managed Auth, make sure the following are already in place:
5238
53* Your MCP server implements [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization), including Protected Resource Metadata (PRM) discovery, and follows the [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices). See our [authentication guide](./authentication) for Claude-specific requirements.
54* Your authorization server registers Claude using either [Anthropic-held client credentials](./authentication#anthropic-held-client-credentials) or a [Client ID Metadata Document](./authentication#dcr-and-cimd-details).
39* Your MCP server implements [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization), including Protected Resource Metadata (PRM) discovery, and follows the [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices). See the [authentication guide](/docs/connectors/building/authentication) for Claude-specific requirements
40* Your authorization server registers Claude using either [Anthropic-held client credentials](/docs/connectors/building/authentication#anthropic-held-client-credentials) or a [Client ID Metadata Document](/docs/connectors/building/authentication#dcr-and-cimd-details)
5541
5642<Warning>
57 Dynamic Client Registration (DCR) is not supported with Enterprise Managed Auth. The identity provider stamps a fixed `client_id` into every assertion it issues, so your authorization server must already recognize that client before the first assertion arrives. A client created on the fly through DCR cannot satisfy this requirement because its identifier will never match the value in the assertion.
43 Dynamic Client Registration (DCR) isn't supported with Enterprise Managed Auth. The identity provider stamps a fixed `client_id` into every assertion it issues, so your authorization server must already recognize that client before the first assertion arrives. A client created on the fly through DCR can't satisfy this requirement because its identifier never matches the value in the assertion.
5844</Warning>
5945
6046## Authorization server requirements
6147
62<Note>
63 This section is for the authorization server operator. If your MCP server relies on a hosted identity platform, there is typically no code to write. Confirm that the platform supports the JWT bearer authorization grant and enable it for your tenant. If you run your own authorization server, the steps below describe what it needs to support.
64</Note>
48Your authorization server must support the JWT bearer authorization grant ([RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)), which lets an authorization server exchange a signed JWT for an access token, and must trust each customer's identity provider as an issuer. This section is for the authorization server operator.
6549
66Support for this flow varies by product. The underlying capability is the JWT bearer authorization grant ([RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)), which lets an authorization server exchange a signed JWT for an access token. Some commercial authorization servers and identity platforms support it today and others do not yet, so the first step is to confirm that yours does and that the customer's identity provider can be registered as a trusted issuer.
50If your MCP server relies on a hosted identity platform, there is typically no code to write. Confirm that the platform supports the JWT bearer authorization grant and enable it for your tenant. Support varies by product, and some commercial authorization servers and identity platforms don't support it yet, so confirm that yours does and that the customer's identity provider can be registered as a trusted issuer. If you run your own authorization server, the steps in this section describe what it needs to support.
6751
6852<Steps>
6953 <Step title="Ensure the JWT bearer grant is supported">
70 Your authorization server must accept `urn:ietf:params:oauth:grant-type:jwt-bearer` at its token endpoint and advertise it in the `grant_types_supported` array of its [authorization server metadata (RFC 8414)](https://datatracker.ietf.org/doc/html/rfc8414):
54 Your authorization server must accept `urn:ietf:params:oauth:grant-type:jwt-bearer` at its token endpoint and advertise it in the `grant_types_supported` array of its [authorization server metadata (RFC 8414)](https://datatracker.ietf.org/doc/html/rfc8414). In this example metadata, the highlighted entry is the one Claude looks for:
7155
72 ```json theme={null}
56 ```json {7} theme={null}
7357 {
7458 "issuer": "https://auth.example.com",
7559 "token_endpoint": "https://auth.example.com/token",
from line 65
8165 }
8266 ```
8367
84 Claude reads this metadata to discover whether your server supports Enterprise Managed Auth. The grant type must be listed here for the feature to be offered to the customer, even if your token endpoint would already accept it silently.
68 Claude reads this metadata to discover whether your server supports Enterprise Managed Auth. The grant type must be listed here for Claude to offer the feature to the customer, even if your token endpoint would already accept it silently.
8569 </Step>
8670
8771 <Step title="Register the trusted issuer">
8872 For each customer, your authorization server needs to trust that customer's identity provider as a JWT issuer. Your authorization server fetches the identity provider's JSON Web Key Set and uses it to verify the signature on every incoming assertion.
8973
90 Your authorization server is responsible for maintaining an explicit allowlist of trusted issuer URLs per tenant rather than accepting any well-formed JWT. An assertion whose `iss` is not on the tenant's allowlist must be rejected with `invalid_grant`, even if the signature is valid.
74 Your authorization server is responsible for maintaining an explicit allowlist of trusted issuer URLs per tenant rather than accepting any well-formed JWT. It must reject an assertion whose `iss` isn't on the tenant's allowlist with `invalid_grant`, even if the signature is valid.
9175
9276 <Warning>
93 Never accept an identity assertion without full validation. As with all OAuth token handling, your authorization server must verify the signature, issuer, audience, expiry, and subject on every request. Use the JWT validation built into your authorization server product. If you need to inspect assertions in your own code, use the validation library or token introspection endpoint provided by your authorization server vendor rather than writing custom verification logic.
77 Never accept an identity assertion without full validation. Your authorization server must verify the signature, issuer, audience, expiry, and subject on every request. Use the JWT validation built into your authorization server product. If you need to inspect assertions in your own code, use the validation library or token introspection endpoint provided by your authorization server vendor rather than writing custom verification logic.
9478 </Warning>
9579 </Step>
9680
9781 <Step title="Understand the token request">
98 Claude sends a form-encoded `POST` to your authorization server's token endpoint:
82 Claude sends a form-encoded `POST` to your authorization server's token endpoint. The highlighted parameters are the JWT bearer grant type, the signed assertion, and the `client_id` your server must already recognize:
9983
100 ```http theme={null}
84 ```http {5-7} theme={null}
10185 POST /token HTTP/1.1
10286 Host: auth.example.com
10387 Content-Type: application/x-www-form-urlencoded
from line 98
11498 Your authorization server validates the assertion according to the [JWT bearer token processing rules (RFC 7523 section 3)](https://datatracker.ietf.org/doc/html/rfc7523#section-3) and returns a standard OAuth token response. Claude then presents the returned access token as a `Bearer` credential on calls to your MCP server, exactly as it does after the interactive flow.
11599
116100 <Note>
117 The access token lifetime is set by your authorization server, and the assertion lifetime is set by the customer's identity provider. Anthropic does not control either value.
101 Your authorization server sets the access token lifetime, and the customer's identity provider sets the assertion lifetime. Anthropic doesn't control either value.
118102 </Note>
119103 </Step>
120104</Steps>
121105
122## Access token lifetime
106### Access token lifetime
123107
124Issue access tokens with whatever lifetime your security policy calls for. A short lifetime, such as one hour, does not force users to repeat single sign-on each time a token expires.
108Issue access tokens with whatever lifetime your security policy calls for. A short lifetime, such as one hour, doesn't force users to repeat single sign-on each time a token expires.
125109
126110When a user signs in to Claude through their organization's SSO, Claude obtains a long-lived refresh token from the identity provider. Claude uses that refresh token to request a fresh identity assertion from the identity provider whenever it needs one, without any user interaction. Claude then exchanges the new assertion at your token endpoint for a new access token. From the user's point of view, the connection stays active for as long as the identity provider's refresh token remains valid.
127111
128The refresh token is issued by the customer's identity provider. Treat it as long-lived today. Identity provider administrators will be able to apply their own lifetime policy in the future.
112The customer's identity provider issues the refresh token. Treat it as long-lived.
129113
130## Testing your implementation
114## Test your implementation
131115
132116End-to-end testing requires a Claude organization with Enterprise Managed Auth enabled and an identity provider tenant configured to issue assertions for your authorization server's audience.
133117
134If your identity provider is Okta, refer to Okta's [Cross App Access participation guide](https://support.okta.com/help/s/article/claude-enterprise-managed-auth-with-okta-cross-app-access-xaa-beta-participation-guide?language=en_US) and configure your organization to be able to test your MCP's XAA implementation.
118If your identity provider is Okta, refer to Okta's [Cross App Access participation guide](https://support.okta.com/help/s/article/claude-enterprise-managed-auth-with-okta-cross-app-access-xaa-beta-participation-guide?language=en_US) and configure your organization so you can test your MCP server's Cross App Access (XAA) implementation.
135119
136### Testing with the cross-app access playground
120### Test with the cross-app access playground
137121
138[Okta's cross-app access playground](https://xaa.dev) lets you exercise the flow without a Claude organization. This is useful while you develop, and when your organization's single sign-on is not on a supported identity provider. On the playground you can:
122[Okta's cross-app access playground](https://xaa.dev) lets you exercise the flow without a Claude organization. The playground is useful while you develop, and when your organization's single sign-on isn't on a supported identity provider. On the playground you can do the following:
139123
140* Walk the full four-step flow end to end against a sandbox IdP, with every token shown decoded
124* Walk the full flow end to end against a sandbox IdP, with every token shown decoded
141125* Point it at your own MCP server or REST API to check resource metadata discovery, the `WWW-Authenticate` hint on `401` responses, and token validation
142126* Point it at your own authorization server to check that it accepts an identity assertion over the JWT bearer grant, mints a scoped access token, and serves its metadata for discovery
143127* Bring your own OIDC or SAML identity provider in place of the sandbox one
144128* Re-run a single failed step and inspect service configurations, discovery documents, and a live event log
145129
146## Admin settings in your product
130## Support customer administrators
147131
132A customer's administrator turns on Enterprise Managed Auth for their organization, so your product needs an admin control for it, setup documentation they can follow, and, for Okta customers, an app that supports Cross App Access.
133
134### Admin settings in your product
135
148136In your product's admin settings, give each customer's administrator a control that turns Enterprise Managed Auth on or off for their organization and a field for their identity provider's issuer URL. When the administrator saves, add that URL to the organization's allowlist of trusted issuers, as described in [Authorization server requirements](#authorization-server-requirements).
149137
150## Provide setup documentation
138### Provide setup documentation
151139
152You can publish documentation that walks an enterprise administrator through enabling Enterprise Managed Auth for your product and add its URL to [your directory listing](./managing-your-listing). Claude shows the link in the Claude admin console when an administrator sets up Enterprise Managed Auth for your connector.
140You can publish documentation that walks an enterprise administrator through enabling Enterprise Managed Auth for your product and add its URL to [your directory listing](/docs/connectors/building/managing-your-listing). Claude shows the link in the Claude admin console when an administrator sets up Enterprise Managed Auth for your connector.
153141
154## Okta Integration Network apps
142### Okta Integration Network apps
155143
156144If your product has an app in the Okta Integration Network, work with Okta to enable Cross App Access (XAA) for that app. Until that app supports Cross App Access, customers who use Okta need to create a custom app in Okta for your product before they can set up Enterprise Managed Auth.
157145
158146## Related resources
159147
160<CardGroup cols={2}>
161 <Card title="Authentication for connectors" icon="key" href="./authentication">
162 Baseline OAuth requirements your server must already meet.
163 </Card>
164
165 <Card title="Lazy authentication" icon="lock-open" href="./lazy-authentication">
166 Defer OAuth until a protected tool is actually invoked.
167 </Card>
168
169 <Card title="Testing your connector" icon="flask" href="./testing">
170 Verify your connector works end to end in Claude.
171 </Card>
172
173 <Card title="Troubleshooting" icon="wrench" href="./troubleshooting">
174 Diagnose common authentication and connection issues.
175 </Card>
176</CardGroup>
148* [Authentication for connectors](/docs/connectors/building/authentication): baseline OAuth requirements your server must already meet
149* [Lazy authentication](/docs/connectors/building/lazy-authentication): ask users to sign in only when Claude reaches a tool that needs their account
150* [Test your connector](/docs/connectors/building/testing): verify your connector works end to end in Claude
151* [Troubleshoot your connector](/docs/connectors/building/troubleshooting): diagnose common authentication and connection issues
177152
No line in this hunk matches that.