One read of Claude Documentationclaude-docs-20261103T220708Z
1 pages moved out of 281 read.
Pages moved
1
significant first
Pages read
281
in this capture
Captured
22:07 UTC
Corpus hash
6206a034ee97
corpus-hash
What this read moved
1-1 of 1connectors/building/enterprise-managed-auth Changed · +13 / -10 lines
from line 18
1818
1919The 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/).
2020
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
2321### Who issues the identity assertion
2422
2523Each 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:
from line 34
3634* 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
3735* 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)
3836
37Enterprise Managed Auth works with [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 exchange and retries the call instead of showing the **Connect** card.
38
39Enterprise 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.
40
3941> [!WARNING]
4042>
4143> 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.
from line 103
101103
102104### Identity assertion claims
103105
104This example shows the decoded payload of a Claude-issued assertion:
106This example shows the decoded payload of an identity assertion:
105107
106108```json theme={null}
107109{
108 "iss": "https://identity.anthropic.com/issuers/<issuer-id>",
110 "iss": "https://issuer.example.com",
109111 "sub": "abcdefghijklmnopqrstuvwxyz",
111113 "aud": ["https://auth.example.com"],
from line 121
119121}
120122```
121123
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`.
124The `iss` claim is either the identity provider's issuer URL or a Claude issuer URL, whichever the workspace trusts. 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`. The example's other values follow a Claude-issued assertion, and an identity provider can send `aud` as a string, leave out `nbf`, and set a different lifetime.
123125
124126* **`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* **`sub` and `email` in Claude-issued assertions**: `sub` is an opaque value that differs under each issuer and, unlike an identity provider's `sub`, doesn't match the subject your product receives through SSO, so [find the user by `email`](#claude-issued-assertions), not by `sub`. Storing that `sub` is optional.
128* **`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. For identity provider-issued assertions, the customer's administrator can enter your tenant ID in their identity provider's settings for your product, if the identity provider has a field for it. For Claude-issued ones, they can enter it 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.
127129
128130### Validate the identity assertion
129131
from line 172
170172
171173Pick the organization by the kind of assertion you're testing:
172174
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.
175* **Claude-issued**: test this kind first, because the organization needs no single sign-on (SSO), verified domain, or identity provider, so a Team organization that you create for testing qualifies as it is. Don't use an organization that signs in to Claude through Okta, because **Claude-issued** isn't available in one that does.
174176* **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.
175177
176To test both kinds of assertion, use two organizations.
178To test both kinds of assertion, use two organizations, because **Claude-issued** isn't available in an organization that signs in to Claude through Okta.
177179
178180### Add your connector and run the connection test
179181
from line 238
236238
237239* Sign-in works end to end for each kind of assertion your server accepts
238240* 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)
241* Your admin settings let a customer's administrator set the trusted issuer for their workspace
242* 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)
240243
241244Then 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.
242245