Enterprise Managed Auth for connectors changedconnectors/building/enterprise-managed-auth
Nearest release: v2.1.318, published 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 3 Nov 2026 20:49 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 3 Nov 2026 21:07 UTC.
Upstream edited
Recorded here
Lines+79added
Lines−108removed
From line
6
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits15to this page, all time
### Identity assertion claims ### Enterprise Managed Auth with lazy authentication ### Test with the cross-app access playground
The whole hunk
from line 6, old and new numbered
/
from line 6
66>
77> Enterprise Managed Auth is available on Claude Team and Enterprise plans. After your authorization server supports it, email `[email protected]` to have [your directory listing](https://claude.com/docs/connectors/building/managing-your-listing.md) marked as supporting Enterprise Managed Auth.
88
9Enterprise Managed Auth (EMA) lets organizations connect their users to your MCP server without sending each user through an OAuth consent screen. Claude presents your authorization server with an identity assertion instead: a signed JSON Web Token (JWT) that vouches for the user's identity. Either the customer's identity provider or Claude signs the assertion, depending on [how the customer set up Enterprise Managed Auth](#who-issues-the-identity-assertion).
9Enterprise Managed Auth (EMA) lets organizations connect their users to your MCP server without sending each user through an OAuth consent screen. Claude presents your authorization server with an identity assertion instead: a signed JSON Web Token (JWT) issued by [the customer's identity provider or by Claude](#who-issues-the-identity-assertion). Your authorization server validates the assertion and returns an access token.
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 available as soon as their administrator enables it.
11As a connector developer, you [make your authorization server accept and validate the assertion](#authorization-server-requirements), [test your implementation](#test-your-implementation), and [give customer administrators the settings and documentation they need](#support-customer-administrators).
1212
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).
14
1513## Understand how Enterprise Managed Auth works
1614
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.
15The diagram shows the exchange between Claude, your authorization server, and your MCP server. Your MCP server receives the same kind of bearer token it would after the interactive OAuth flow.
1816
1917
2018
21The 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 (ID-JAG)](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).
19The flow is defined by the [MCP enterprise managed authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization), and the identity assertion is based on the [Identity Assertion JWT Authorization Grant (ID-JAG)](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/).
2220
21With [lazy authentication](https://claude.com/docs/connectors/building/lazy-authentication.md), when your MCP server answers a tool call with `401 Unauthorized` and the user's organization has Enterprise Managed Auth configured for your connector, Claude runs the same exchange and retries the call instead of showing the **Connect** card.
22
2323### Who issues the identity assertion
2424
25Each customer workspace in your product trusts one issuer of identity assertions. The issuer for a customer is one of the following:
25Each customer workspace, meaning the customer's tenant in your product, trusts one issuer of identity assertions. The issuer for a customer is one of the following:
2626
27* **Identity provider-issued**: the customer's identity provider issues and signs the assertion for a user who signed in to Claude through the organization's single sign-on (SSO). The trusted issuer is the identity provider's issuer URL. The customer needs an identity provider that can issue identity assertions.
28* **Claude-issued**: Claude issues and signs the assertion under an issuer URL that belongs to the customer's Claude organization. The URL has the form `https://identity.anthropic.com/issuers/<issuer-id>`. The trusted issuer is that Claude issuer URL. Claude-issued assertions are in beta.
27* **Identity provider-issued**: the customer's identity provider issues and signs the assertion under its own issuer URL, for a user who signed in to Claude through the organization's single sign-on (SSO).
28* **Claude-issued**: Claude issues and signs the assertion under an issuer URL that belongs to the customer's Claude organization. The URL has the form `https://identity.anthropic.com/issuers/<issuer-id>`, where `<issuer-id>` differs for each Claude organization and isn't the organization's ID. Claude-issued assertions are in beta.
2929
30Where Claude's managed authorization setup offers both, the administrator sees them under **Identity source** as **IdP-managed** and **Claude-issued**. The token format and the exchange at your token endpoint are the same in both cases. The issuer publishes its signing keys as a JSON Web Key Set, and your authorization server fetches that key set to verify each assertion.
30The token format and the exchange at your token endpoint are the same in both cases.
3131
32### Enterprise Managed Auth with lazy authentication
33
34Enterprise Managed Auth also works with [lazy authentication](https://claude.com/docs/connectors/building/lazy-authentication.md). 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.
35
36Your MCP server returns the same `401` with a `WWW-Authenticate` header as described in the [lazy authentication guide](https://claude.com/docs/connectors/building/lazy-authentication.md#answer-a-protected-call-with-401-before-the-mcp-sdk-runs). Your authorization server must still meet the [authorization server requirements](#authorization-server-requirements).
37
38Enterprise 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.
39
4032## Prerequisites
4133
4234Before adding Enterprise Managed Auth, make sure the following are already in place:
4335
44* 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](https://claude.com/docs/connectors/building/authentication.md) for Claude-specific requirements
36* Your MCP server implements [MCP authorization](https://modelcontextprotocol.io/specification/draft/basic/authorization), including Protected Resource Metadata (PRM) discovery. See the [authentication guide](https://claude.com/docs/connectors/building/authentication.md) for Claude-specific requirements
4537* Your authorization server registers Claude using either [Anthropic-held client credentials](https://claude.com/docs/connectors/building/authentication.md#anthropic-held-client-credentials) or a [Client ID Metadata Document](https://claude.com/docs/connectors/building/authentication.md#dcr-and-cimd-details)
4638
4739> [!WARNING]
4840>
49> Dynamic Client Registration (DCR) isn't supported with Enterprise Managed Auth. Register Claude through [Anthropic-held client credentials](https://claude.com/docs/connectors/building/authentication.md#anthropic-held-client-credentials) or a [Client ID Metadata Document](https://claude.com/docs/connectors/building/authentication.md#dcr-and-cimd-details) before the first assertion arrives. When the customer's identity provider issues the assertions, it stamps a fixed `client_id` into every one, so your authorization server must already recognize that client. A client created on the fly through DCR can't satisfy this requirement because its identifier never matches the value in the assertion.
41> Dynamic Client Registration (DCR) isn't supported with Enterprise Managed Auth. When the customer's identity provider issues the assertions, it stamps a fixed `client_id` into every one, so your authorization server must recognize that client before the first assertion arrives. The identifier of a client created through DCR never matches the `client_id` that the identity provider stamps.
5042
5143## Authorization server requirements
5244
53Your 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 one issuer of identity assertions for each customer. This section is for the authorization server operator.
45If your MCP server relies on a hosted identity platform, confirm that the platform supports the JWT bearer authorization grant ([RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523)), runs every check in [Validate the identity assertion](#validate-the-identity-assertion), and can register an issuer URL that doesn't belong to the customer's identity provider as a trusted issuer.
5446
55If your MCP server relies on a hosted identity platform, you may not need to write code. Confirm that the platform supports the JWT bearer authorization grant, that it runs every check in [Validate the identity assertion](#validate-the-identity-assertion), and that it can register an issuer URL that isn't the customer's identity provider as a trusted issuer. Support varies by product, and some commercial authorization servers and identity platforms don't support the grant yet. If you run your own authorization server, the steps in this section describe what it needs to support.
56
5747**1. Ensure the JWT bearer grant is supported**
5848
59Your 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:
49Your 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 grant type is highlighted:
6050
6151```json {7} theme={null}
6252{
from line 60
7060}
7161```
7262
73Claude 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.
63List the grant type here even if your token endpoint already accepts it.
7464
7565Claude sends assertions when your metadata also meets these conditions:
7666
7767* The `issuer` matches the URL Claude fetched the metadata from, as [RFC 8414 section 3.3](https://datatracker.ietf.org/doc/html/rfc8414#section-3.3) requires
7868* The `token_endpoint` is on the same registrable domain as the `issuer`. Different hosts under that domain work, such as `https://api.example.com/token` for the issuer `https://www.example.com`
79* For Claude-issued assertions, the `issuer` is a plain `https` URL on a public domain name, with no user name, query, fragment, percent-escapes, or characters such as commas and semicolons
8069
8170Keep the `issuer` value exactly as published, trailing slash included. A Claude-issued setup records the value, and a changed value stops sign-ins for that customer.
8271
8372**2. Register the trusted issuer**
8473
85For each customer workspace, your authorization server trusts one issuer of identity assertions. The customer's administrator gives you the issuer URL, which is one of the following:
74Bind each customer workspace to one trusted issuer rather than accepting any well-formed JWT, and allow that issuer to be a Claude issuer URL, not only a URL on an identity provider's domain. The binding happens in [your product's admin settings](#admin-settings-in-your-product), where a workspace's administrator enters the issuer URL and your authorization server stores it as that workspace's trusted issuer. Resolve each assertion to exactly one workspace, as [Validate the identity assertion](#validate-the-identity-assertion) describes.
8675
87* **Identity provider-issued**: the issuer URL of the customer's identity provider
88* **Claude-issued**: a Claude issuer URL of the form `https://identity.anthropic.com/issuers/<issuer-id>`, where `<issuer-id>` differs for each customer's Claude organization
89
90Keep an explicit trusted issuer for each workspace rather than accepting any well-formed JWT. Allow that issuer to be a Claude issuer URL, not only a URL on an identity provider's domain. The first check in [Validate the identity assertion](#validate-the-identity-assertion) rejects an assertion whose `iss` isn't an exact match for the workspace's registered issuer, before any key is fetched.
91
92Bind each issuer to one workspace, and resolve each assertion to exactly one workspace. If the same issuer URL is registered for more than one workspace, don't guess between them. Find the one workspace an assertion is for as [Validate the identity assertion](#validate-the-identity-assertion) describes.
93
9476> [!WARNING]
9577>
96> Never accept an identity assertion without full validation. Your authorization server must run every check in [Validate the identity assertion](#validate-the-identity-assertion) 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 your own signature verification.
78> Use the JWT validation built into your authorization server product, or its vendor's validation library, rather than writing your own signature verification.
9779
9880**3. Understand the token request**
9981
from line 93
11193&resource=https://mcp.example.com
11294```
11395
114Client authentication is left out of this example. The `assertion` parameter carries the signed JWT. The `client_id` is the value Claude is registered under at your authorization server, which for a Client ID Metadata Document is the document's URL. If that client has a secret or key, require it on this request. Answer at the `token_endpoint` URL itself, because Claude doesn't follow redirects on this request.
96Client authentication is left out of this example. The `client_id` is the value Claude is registered under at your authorization server, which for a Client ID Metadata Document is the document's URL. If that client has a secret or key, require it on this request. Answer at the `token_endpoint` URL itself, because Claude doesn't follow redirects on this request.
11597
116Claude includes the `resource` parameter ([Resource Indicators, RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)) as follows:
98A Claude-issued request always carries the `resource` parameter ([Resource Indicators, RFC 8707](https://www.rfc-editor.org/rfc/rfc8707)), set to the `resource` in your Protected Resource Metadata when that is your MCP server's URL or a parent of it, and otherwise to your MCP server's URL. An identity provider-issued request carries it whenever the customer's identity provider supports forwarding it. Accept the request whether or not `resource` is present, and use it for audience binding when it is.
11799
118* **Identity provider-issued**: whenever the customer's identity provider supports forwarding it. Some identity provider configurations can't pass a resource indicator through
119* **Claude-issued**: always, set to the `resource` in your Protected Resource Metadata when that is your MCP server's URL or a parent of it, and otherwise to your MCP server's URL
100Your authorization server [validates the assertion](#validate-the-identity-assertion) and returns a standard OAuth token response with an access token. Include `expires_in` so Claude knows when to get a new token. Claude doesn't use a refresh token from this grant, so don't issue one for it. Keep issuing refresh tokens in the interactive OAuth flow, which relies on them.
120101
121Accept the request whether or not `resource` is present, and use it for audience binding when it is.
102### Identity assertion claims
122103
123Your authorization server [validates the assertion](#validate-the-identity-assertion) and returns a standard OAuth token response with an access token. Include `expires_in` so Claude knows when to get a new token. Claude doesn't use a refresh token from this grant, so don't issue one. 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.
104This example shows the decoded payload of a Claude-issued assertion:
124105
106```json theme={null}
107{
108 "iss": "https://identity.anthropic.com/issuers/<issuer-id>",
109 "sub": "abcdefghijklmnopqrstuvwxyz",
110 "email": "[email protected]",
111 "aud": ["https://auth.example.com"],
112 "client_id": "your-registered-client-id",
113 "scope": "read write",
114 "aud_tenant": "your-tenant-id",
115 "iat": 1790000000,
116 "nbf": 1789999985,
117 "exp": 1790000045,
118 "jti": "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
119}
120```
121
122An identity provider-issued assertion has the identity provider's issuer URL as `iss`. The ID-JAG format makes `email`, `scope`, and `aud_tenant` optional, so an identity provider can leave them out. A Claude-issued assertion always carries `email`, and can leave out `scope` and `aud_tenant`.
123
124* **`sub` in identity provider-issued assertions**: `sub` is the identity provider's identifier for the user, and the ID-JAG format requires it to match the subject your product receives when that user signs in through SSO. Find the user by `iss` and `sub` together, among the members of the workspace the assertion resolved to.
125* **`sub` and `email` in Claude-issued assertions**: `sub` is an opaque value that differs under each issuer and means nothing to your product, so [find the user by `email`](#claude-issued-assertions), not by `sub`. Storing that `sub` is optional.
126* **`aud_tenant`**: your own identifier for a customer's workspace, for products where `iss` alone doesn't identify one workspace, such as when one customer has several workspaces that trust the same issuer. A Claude-issued assertion carries it when the customer's administrator entered your tenant ID in Claude's managed authorization setup for your connector. Claude doesn't check the value, so use it only to choose the workspace, and still run the issuer check in [Validate the identity assertion](#validate-the-identity-assertion) against that workspace's registered issuer.
127
125128### Validate the identity assertion
126129
127Run these checks, in this order, on every token request, whichever kind of issuer signed the assertion. When a check fails, reject the request with `invalid_grant`, as the [JWT bearer token processing rules (RFC 7523 section 3)](https://datatracker.ietf.org/doc/html/rfc7523#section-3) require.
130Run these checks, in this order, on every token request. When a check fails, reject the request with `invalid_grant`, as the [JWT bearer token processing rules (RFC 7523 section 3)](https://datatracker.ietf.org/doc/html/rfc7523#section-3) require.
128131
129Before the first check, find the one workspace the assertion is for. If you identify workspaces by your own tenant ID and the assertion carries `aud_tenant`, take the workspace that `aud_tenant` names. A Claude-issued assertion carries the claim when the customer's administrator entered your tenant ID in Claude's managed authorization setup for your connector, and Claude doesn't check the value. Otherwise, take the workspace that registered `iss`, and reject the assertion if no workspace or more than one did.
132Before the first check, find the one workspace the assertion is for. If you identify workspaces by your own tenant ID and the assertion carries [`aud_tenant`](#identity-assertion-claims), take the workspace that `aud_tenant` names. Otherwise, take the workspace that registered `iss`, and reject the assertion if no workspace or more than one did.
130133
1311341. **Issuer**: `iss` equals, as an exact string, the trusted issuer registered for that workspace. A prefix or host match admits other customers' users. Check this before you fetch any keys.
1321352. **Keys**: fetch `<iss>/.well-known/openid-configuration`, confirm that the document's `issuer` equals `iss`, and fetch the key set from the document's `jwks_uri`. Use only keys from that key set, and ignore any key or key URL carried in the assertion's header. Don't pin a single key. Cache keys for as long as the response headers allow, and fetch them again when an assertion names a `kid` you haven't seen.
from line 137
1341374. **Type**: the `typ` header is `oauth-id-jag+jwt`. Check `typ` yourself if your JWT library doesn't check it.
1351385. **Audience**: `aud` is your authorization server's own `issuer` value, exactly as your metadata publishes it. The claim can arrive as a string or as a JSON array with one element, so use your library's audience option rather than comparing the raw claim text.
1361396. **Client**: the `client_id` claim equals the `client_id` of this request.
1377. **Subject**: a `sub` claim is present. [Claude-issued assertions](#claude-issued-assertions) identify the user by `email`, not by `sub`.
1407. **Subject**: a `sub` claim is present. Whether you find the user by `sub` or by `email` [depends on the issuer](#identity-assertion-claims).
1381418. **Time**: `exp` hasn't passed, `iat` isn't in the future, and `nbf`, when present, has passed. Allow at most 60 seconds of clock skew.
1391429. **Replay**: a `jti` claim is present. Accept each `jti` from an issuer once, and remember it at least until the assertion's `exp` plus your clock-skew allowance. Treat `jti` as an opaque string. If you can't check whether a `jti` was already used, reject the request.
140143
from line 145
142145
143146### Claude-issued assertions
144147
145Claude signs a Claude-issued assertion under the issuer URL of the customer's Claude organization, and the checks in [Validate the identity assertion](#validate-the-identity-assertion) apply to it unchanged. This example shows the decoded payload of one:
148These points apply to Claude-issued assertions:
146149
147```json theme={null}
148{
149 "iss": "https://identity.anthropic.com/issuers/<issuer-id>",
150 "sub": "abcdefghijklmnopqrstuvwxyz",
151 "email": "[email protected]",
152 "aud": ["https://auth.example.com"],
153 "client_id": "your-registered-client-id",
154 "scope": "read write",
155 "aud_tenant": "your-tenant-id",
156 "iat": 1790000000,
157 "nbf": 1789999985,
158 "exp": 1790000060,
159 "jti": "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
160}
161```
150* **What the assertion says**: the user is a current member of the customer's Claude organization, and `email` is the address of their Claude account, in lowercase. The assertion doesn't say that the user signed in through the customer's identity provider or used multi-factor authentication, and it carries no group claims.
151* **Discovery document**: a Claude issuer's discovery document, at `<iss>/.well-known/openid-configuration`, holds `issuer` and `jwks_uri` and has no `authorization_endpoint` or `token_endpoint`. Read `issuer` and `jwks_uri` from it yourself rather than passing it to a validator that expects a full OpenID Connect provider configuration.
152* **Lifetime**: each assertion expires within a minute, and each sign-in and each renewal gets a new assertion with a new `jti`.
153* **User lookup**: find the user by `email` among the members of the workspace the assertion resolved to. Compare the whole address, ignore letter case, and keep dots and plus tags as they are. If no member of the workspace has the address, reject the request, or create the user only when the address is on an email domain the workspace has verified with your service.
162154
163* **What the assertion says**: the user is a current member of the customer's Claude organization, and `email` is the address of their Claude account, in lowercase. The assertion doesn't say that the user signed in through the customer's identity provider or used multi-factor authentication, and it carries no `sub_id` claim and no groups.
164* **Signing keys**: every Claude issuer signs with the same keys, so a valid signature doesn't tell you which Claude organization an assertion is for. Only `iss` does.
165* **Discovery document**: a Claude issuer serves its discovery document at `<iss>/.well-known/openid-configuration`. The document holds `issuer` and `jwks_uri` and has no `authorization_endpoint` or `token_endpoint`, so read those two members yourself rather than passing the document to a validator that expects a full OpenID Connect provider configuration.
166* **Lifetime**: each assertion expires within a minute. Claude signs a new assertion, with a new `jti`, for each sign-in and each renewal.
167* **User lookup**: find the user by `email` among the members of the workspace the assertion resolved to. Compare the whole address, ignore letter case, and keep dots and plus tags as they are. The `sub` claim is an opaque value that differs under each issuer, so don't look users up by it. Storing it is optional. If no member of the workspace has the address, reject the request, or create the user only when the address is on an email domain the workspace has verified with your service.
168
169155> [!WARNING]
170156>
171> Sign a user in from a Claude-issued assertion only when your service has verified that user's email address, or when the address is on an email domain the workspace has verified. A Claude issuer URL isn't a secret, so someone can register another customer's issuer URL in a workspace they control.
157> Sign a user in by `email` only when your service has verified that user's email address, or when the address is on an email domain the workspace has verified. An issuer URL isn't a secret, and whoever runs an identity provider can put any address in `email`, so someone can register another customer's issuer URL, or an identity provider of their own, in a workspace they control.
172158
173159### Access token lifetime
174160
175Issue access tokens with whatever lifetime your security policy calls for. A short lifetime, such as one hour, doesn't make users sign in again each time a token expires. Claude gets a new identity assertion without any user interaction and exchanges it at your token endpoint for a new access token. Claude gets each new assertion as follows:
161Issue access tokens with whatever lifetime your security policy calls for. A short lifetime, such as one hour, doesn't make users sign in again each time a token expires. Claude gets a new identity assertion without any user interaction and exchanges it at your token endpoint for a new access token.
176162
177* **Identity provider-issued**: when a user signs in to Claude through their organization's SSO, Claude obtains a long-lived refresh token from the identity provider and uses it to request each new assertion. The connection stays active for as long as that refresh token remains valid
178* **Claude-issued**: Claude signs each new assertion itself, for as long as the user remains a member of the customer's Claude organization
179
180163When a user is removed from the customer's Claude organization, Claude stops signing Claude-issued assertions for them. Access tokens you already issued stay valid, so your access token lifetime bounds how long a removed user keeps access.
181164
182165## Test your implementation
183166
184Test end to end from a Claude organization on a Team or Enterprise plan, signed in as an Owner or Primary Owner. You can use your company's own organization or [a Team organization that you create for testing](https://support.claude.com/en/articles/9267247-get-started-with-the-team-plan). While you develop, [Okta's cross-app access playground](#test-with-the-cross-app-access-playground) exercises your authorization server and MCP server without a Claude organization.
167Test end to end from a Claude organization on a Team or Enterprise plan, signed in as an Owner or Primary Owner. You can use your company's own organization or [a Team organization that you create for testing](https://support.claude.com/en/articles/9267247-get-started-with-the-team-plan). While you develop, Okta's [Cross App Access sandbox](https://xaa.dev) exercises your authorization server and MCP server without a Claude organization. Point the sandbox at your authorization server to check that your server accepts an identity assertion over the JWT bearer grant, mints a scoped access token, and serves its metadata for discovery.
185168
186169### Choose a test organization
187170
188171Pick the organization by the kind of assertion you're testing:
189172
190* **Claude-issued**: use a Team or Enterprise organization that doesn't use Okta for single sign-on (SSO), because **Claude-issued** isn't available in an organization that signs in to Claude through Okta. The organization doesn't need SSO, a verified domain, or an identity provider, so a Team organization that you create for testing qualifies as it is. If you can't choose **Claude-issued** in your company's organization, create a Team organization for testing. In either organization, go straight to [Add your connector and run the connection test](#add-your-connector-and-run-the-connection-test).
191* **Identity provider-issued**: use an organization that signs in to Claude through Okta. If your company's organization does, test there. Otherwise, you need an Okta org, such as an integrator org from Okta's [Integrator Free Plan](https://developer.okta.com/signup/), and a Team organization that you create. Follow [Set up single sign-on](https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso) to verify a domain for the Team organization and connect SSO, choosing Okta as the provider. In the Okta org, give yourself and each test user an address on that domain. In either Claude organization, register Claude and your connector in the Okta org as [Add your connector and run the connection test](#add-your-connector-and-run-the-connection-test) describes, and sign in to Claude through SSO before you run the connection test.
173* **Claude-issued**: use a Team or Enterprise organization that doesn't sign in to Claude through Okta, because **Claude-issued** isn't available in one that does. The organization doesn't need single sign-on (SSO), a verified domain, or an identity provider, so a Team organization that you create for testing qualifies as it is.
174* **Identity provider-issued**: use an organization that signs in to Claude through Okta. If your company's organization does, test there. Otherwise, you need an Okta org, such as an integrator org from Okta's [Integrator Free Plan](https://developer.okta.com/signup/), and a Team organization that you create. Follow [Set up single sign-on](https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso) to verify a domain for the Team organization and connect SSO, choosing Okta as the provider. In the Okta org, give yourself and each test user an address on that domain. Sign in to Claude through SSO before you run the connection test.
192175
193A Claude-issued test runs metadata discovery, then presents your token endpoint with a real assertion that Claude issued and signed. It doesn't involve an identity provider. To test both kinds of assertion, use two organizations.
176To test both kinds of assertion, use two organizations.
194177
195178### Add your connector and run the connection test
196179
from line 181
198181
199182Add your MCP server as a custom connector for the test organization, as [Add the connector for the organization](https://claude.com/docs/connectors/custom/add-unlisted.md#add-the-connector-for-the-organization) describes.
200183
201If your MCP server is already in the [Connectors Directory](https://claude.com/docs/connectors/directory.md), add it as a custom connector at your listing's URL rather than from the directory. A connector added from the directory shows **Managed authorization** only after your listing is marked as supporting Enterprise Managed Auth. A custom connector shows it either way. The custom connector opens on your listing's page, where the **Authentication** section is on the **Configuration** tab.
184If your MCP server is already in the [Connectors Directory](https://claude.com/docs/connectors/directory.md), add it as a custom connector at your listing's URL rather than from the directory. A connector added from the directory shows **Managed authorization** only after your listing is marked as supporting Enterprise Managed Auth. The custom connector opens on your listing's page, where the **Authentication** section is on the **Configuration** tab.
202185
203186An organization can have one connector at a URL, so if yours already has your connector from the directory, test in a Team organization that you create for testing.
204187
205188**2. Open the managed authorization setup**
206189
207Open the connector you added. In its **Authentication** section, which is separate from the **Authentication** setting you chose while adding the connector, click **Set up** on the **Managed authorization** row. Under **Identity source**, choose **IdP-managed** or **Claude-issued**.
190Open the connector you added. In its **Authentication** section, which is separate from the **Authentication** setting you chose while adding the connector, click **Set up** on the **Managed authorization** row. Under **Identity source**, choose **IdP-managed** for identity provider-issued assertions or **Claude-issued** for Claude-issued ones.
208191
209192For **IdP-managed**, follow the first step under **Setup guide** to register Claude and your connector in your Okta org. For the steps in the Okta Admin Console, see Okta's [Cross App Access guide for AI agents](https://developer.okta.com/docs/guides/xaa-agent-to-app/main/).
210193
from line 204
221204Check each of these cases before you launch:
222205
223206* An assertion from the workspace's registered issuer signs the right user in
224* An assertion that carries another customer's issuer URL is refused
207* An assertion whose `iss` no workspace has registered is refused
208* An assertion whose `aud_tenant` names a workspace that registered a different issuer is refused
225209* An assertion whose `iss` is registered for more than one workspace is refused, unless you identify workspaces by your own tenant ID and the assertion's `aud_tenant` names one of those workspaces
226210* The same assertion presented a second time is refused
227211* An assertion whose `aud` isn't your authorization server's issuer is refused
from line 212
228212* For a Claude-issued assertion, the user is found by verified email within the workspace the assertion resolved to, not by `sub`
229213* A Claude-issued assertion for an address your service hasn't verified, on a domain the workspace hasn't verified, is refused
230214
231### Test with the cross-app access playground
232
233[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:
234
235* Walk the full flow end to end against a sandbox IdP, with every token shown decoded
236* 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
237* 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
238* Bring your own OIDC or SAML identity provider in place of the sandbox one
239* Re-run a single failed step and inspect service configurations, discovery documents, and a live event log
240
241215## Support customer administrators
242216
243A 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.
217A customer's administrator turns on Enterprise Managed Auth for their organization.
244218
245219### Admin settings in your product
246220
247In your product's admin settings, give each customer's administrator a control that turns Enterprise Managed Auth on or off for their workspace and a field for the trusted issuer URL. Accept only an `https` URL in the field, and let only the workspace's administrators set it. The administrator copies the URL from their identity provider or, for Claude-issued assertions, from the **Issuer URL** box in Claude's managed authorization setup for your connector. When the administrator saves, register the URL as the workspace's trusted issuer, as described in [Authorization server requirements](#authorization-server-requirements).
221In your product's admin settings, give each customer's administrator a control that turns Enterprise Managed Auth on or off for their workspace and a field for the trusted issuer URL. Accept only an `https` URL in the field, and let only the workspace's administrators set it. The administrator copies the URL from their identity provider or, for Claude-issued assertions, from the **Issuer URL** box in Claude's managed authorization setup for your connector. When the administrator saves, register the URL as that workspace's trusted issuer.
248222
249If you identify workspaces by your own tenant ID, show that ID in the same settings. The administrator enters it in the **Tenant ID (optional)** field in Claude's managed authorization setup for your connector, and it then arrives in each Claude-issued assertion as `aud_tenant`.
223If you identify workspaces by your own tenant ID, show that ID in the same settings. The administrator enters it in the **Tenant ID (optional)** field in Claude's managed authorization setup for your connector, and it then arrives in each Claude-issued assertion as [`aud_tenant`](#identity-assertion-claims).
250224
251225### Provide setup documentation
252226
from line 235
261235Confirm each of the following before you ask Anthropic to mark your directory listing as supporting Enterprise Managed Auth:
262236
263237* Sign-in works end to end for each kind of assertion your server accepts
264* Every case in [Test your implementation](#test-your-implementation) passes, including the refused ones
265* Your admin settings let a customer's administrator set the trusted issuer for their workspace
266* Your setup documentation for administrators is published, and its URL is on [your directory listing](https://claude.com/docs/connectors/building/managing-your-listing.md)
238* Every case in [Cases to check before launch](#cases-to-check-before-launch) passes, including the refused ones
239* Your [admin settings and setup documentation](#support-customer-administrators) are published, and the documentation's URL is on [your directory listing](https://claude.com/docs/connectors/building/managing-your-listing.md)
267240
268241Then email `[email protected]` with your listing's name and the kinds of assertion your server accepts. If your connector isn't listed yet, [submit it](https://claude.com/docs/connectors/building/submission.md) before you email. Anthropic reviews the request and sets which kinds the listing is marked as supporting.
269
270Until the listing is marked, Claude doesn't offer managed authorization for it to customers' administrators. An administrator can choose **Claude-issued** for your listing only after it is marked for Claude-issued assertions.
271242
272243## Related resources
273244
No line in this hunk matches that.