# Claude Auto-Connect for Organizations > Connect your whole organization's Claude Team or Enterprise members to Ditto without a consent screen per person, using Enterprise Managed Auth with a Claude-issued or identity-provider issuer. --- Claude auto-connect (Anthropic calls it Enterprise Managed Auth) lets an organization's members use Ditto in Claude without each person going through the Ditto sign-in and consent screen. When a member's Claude needs Ditto, Claude presents Ditto with a signed identity assertion from the issuer your organization trusts, and Ditto returns an access token for that member. This guide is for **Ditto organization owners and admins** who are also **Owners or Primary Owners of a Claude Team or Enterprise organization**. > **Availability.** Claude auto-connect is in early access. It works only for Ditto organizations where Ditto has turned it on, and only those organizations see **Claude auto-connect** in the Ditto admin console. If your organization does not see it, ask Ditto support to enable it. Ditto's public OAuth metadata lists the JWT bearer grant for every organization: that tells Claude Ditto supports managed authorization in general, not that it is active for yours. On Claude's side, Claude-issued auth is in beta and IdP-managed auth currently requires Okta single sign-on. ## What members get | | With auto-connect | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- | | What a session can reach | Your Ditto organization's main Space only, not the member's personal memories, agents, workflows or connected apps | | Tools | Search, read, save, update and delete memories in that Space | | Viewers | Read-only | | Who can sign in | Active members of your Ditto organization whose Ditto email address is **verified** | | When access ends | Immediately on the member's next request after you remove them or switch auto-connect off; otherwise access tokens last one hour | | Refresh tokens | None. Claude fetches a new assertion when a token expires | Members who want Ditto to reach their personal memories can connect Ditto themselves with the regular [MCP sign-in](/docs/mcp-server), where your Claude organization's settings allow it (see [When members sign in themselves instead](#when-members-sign-in-themselves-instead)). ## Before you start - A **team** Ditto organization (personal workspaces cannot use auto-connect), and the owner or admin role in it. - A Claude **Team or Enterprise** organization, and the Owner or Primary Owner role there. - Claude auto-connect enabled for your Ditto organization (see **Availability** above). - Each member who will auto-connect has joined your Ditto organization and verified their email in Ditto. For Claude-issued sign-ins the member's Ditto email must be the same address as their Claude account. ## Choose an identity source | Identity source | Use it when | Issuer URL looks like | | ------------------------ | ------------------------------------------------------------- | ----------------------------------------------------------------------------------- | | **Claude-issued** (beta) | Your Claude organization does not sign in through Okta | `https://identity.anthropic.com/issuers/` | | **IdP-managed** | Your Claude organization signs in through Okta single sign-on | Your identity provider's issuer, for example `https://acme.okta.com/oauth2/default` | Each connector uses one identity source at a time. Claude's [connector developer guide](https://claude.com/docs/connectors/building/enterprise-managed-auth) adds that **Claude-issued** isn't offered in a Claude organization that signs in through Okta. Once a connector is switched to **IdP-managed**, Claude offers **Claude-issued** again only if single sign-on is removed from the organization. ## Set up Claude-issued auto-connect 1. In Claude, go to [**Organization settings → Connectors**](https://claude.ai/admin-settings/connectors). Add Ditto if you have not already (from the directory, or as a custom connector at `https://api.heyditto.ai/mcp`), then open it. 2. On the connector's **Configuration** tab, click **Set up** next to **Managed authorization**. 3. On the **Connect** step, choose **Claude-issued** as the **Identity source**, and copy the **Issuer URL** Claude shows. 4. In the [Ditto admin console](https://admin.heyditto.ai), open your organization and go to **Access → Claude auto-connect**. Paste the URL into **Trusted issuer URL** exactly as shown, turn on **Auto-connect members from Claude**, and click **Save**. 5. Optional: if more than one of your Ditto organizations trusts the same issuer, copy the **Tenant ID** shown on the Ditto page into Claude's tenant field. Otherwise leave it empty. 6. Back in Claude, click **Test connection**. If it fails, see [Troubleshooting](#troubleshooting). 7. Click **Enable and continue**. 8. Choose who gets the connector. By default all roles get it. To pilot with one team, select only that team's custom role. ## Set up identity-provider (Okta) auto-connect 1. In Claude, open the Ditto connector's **Configuration** tab and click **Set up** next to **Managed authorization**. On the **Connect** step, choose **IdP-managed** and confirm the identity provider connection. 2. Follow Claude's **Setup guide** to register Claude and Ditto in your Okta org (Okta calls this Cross App Access). If you register Ditto in Okta yourself, use this **client ID** for Ditto: `https://claude.ai/oauth/mcp-oauth-client-metadata`. It is also shown on the Ditto **Claude auto-connect** page. 3. In the Ditto admin console, paste your Okta authorization server's **issuer** into **Trusted issuer URL**, turn auto-connect on and click **Save**. 4. In Claude, click **Run test**. 5. On the **Roles** step, choose who gets the connector. The built-in roles (User, Admin, Owner, Primary owner) are selected together; custom roles are selected one by one. To pilot with one team, check only that team's custom role. 6. On the **Scopes** step, choose `mcp:read` and `mcp:write`. These apply to every selected role. Ditto never grants an auto-connect session more than these two scopes, and gives Viewers `mcp:read` only. 7. Click **Save & turn on**. Afterwards the connector's **Configuration** tab shows **Applied roles** and **Scopes**. To widen a pilot, click **Edit** next to **Applied roles**. The first time a member signs in through your identity provider, Ditto matches them by verified email and remembers their identity-provider user ID. Later sign-ins use that ID, so a member keeps signing in even if their email changes in Okta. Another identity-provider user cannot take over a member Ditto has already matched. ### What Ditto requires of an Okta assertion Claude gets an identity assertion (an ID-JAG) from Okta for a member who signed in to Claude through your organization's Okta single sign-on, and passes it to Ditto. Ditto accepts it only when all of the following hold. They follow the checks in Claude's [connector developer guide](https://claude.com/docs/connectors/building/enterprise-managed-auth#validate-the-identity-assertion). | Claim or property | Ditto requires | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `iss` | Exactly the **Trusted issuer URL** saved in Ditto (your Okta authorization server's issuer, trailing slash included) | | Signing keys | Published at `/.well-known/openid-configuration`, whose `issuer` equals `iss`, with an `https` `jwks_uri`. Keys carried in the assertion's header are ignored | | `alg` | `RS256` (RSA key of at least 2048 bits) or `ES256`. Every other algorithm is refused | | `typ` header | `oauth-id-jag+jwt` | | `aud` | `https://api.heyditto.ai` | | `client_id` | `https://claude.ai/oauth/mcp-oauth-client-metadata`, the client Claude presents to Ditto. Registering Ditto through Claude's setup guide fills this in for you | | `sub` | Present. Okta's identifier for the user | | `email` | Needed the first time a member signs in: it must equal the member's verified Ditto email. If `email_verified` is present it must be `true` | | `exp`, `iat` | Both present; `exp` not passed and `iat` not in the future, within 60 seconds of clock skew. `nbf`, if present, must have passed | | `jti` | Present. Each assertion is accepted once | | `scope` | Optional. If present, Ditto grants only the overlap with `mcp:read mcp:write` (Viewers: `mcp:read`) | | `aud_tenant` | Optional. Needed only when more than one of your Ditto organizations trusts the same Okta issuer. Then Okta itself must put your Ditto organization's **Tenant ID** in the assertion as `aud_tenant`, which works only if Okta lets you enter a tenant ID for Ditto; otherwise give each Ditto organization a distinct trusted issuer, for example a separate Okta authorization server. Claude's **Tenant ID (optional)** field applies only to Claude-issued assertions | Ditto has no Okta single sign-on of its own, so it can't match Okta's `sub` to a Ditto account directly. On a member's first sign-in it matches the verified email and then remembers `iss` and `sub` for that member, as described above. ## Before you announce it Ask two or three members to make a real request to Ditto in Claude. They should find Ditto already connected, with no sign-in page or consent screen. ## When members sign in themselves instead Members can reach Ditto through **browser sign-in**, where the member signs in to Ditto in a browser and approves the consent screen, only where your Claude organization's settings allow it: **Browser sign-in** must be on for the Ditto connector, and the member's role must not limit Ditto to managed authorization in its **How members connect** setting. Claude's [admin guide](https://support.claude.com/en/articles/15537633-auto-connect-your-organization-s-apps-to-claude) describes when that happens: - **Both methods on.** **Browser sign-in** and **Managed authorization** can be on for one connector at the same time. Claude then tries managed authorization first and, if it fails, asks the member to sign in individually. Claude describes this as a way to keep members from being locked out while an identity-provider problem is fixed. - **Per-role setting.** A custom role's **Connectors** tab has **How members connect**: **Individually** (members sign in with their own accounts), **Managed authorization** (members connect through the identity source set for each connector) or **Set per connector**. - **No matching account.** With Claude-issued auth, a member whose Claude email doesn't match an account isn't connected automatically and sees the usual **Connect** prompt. In Ditto, that means no active member of your organization has that verified email. - **Managed authorization disabled.** After **Disable**, Claude's guide says members connect to the service themselves. For Ditto that means browser sign-in, so it applies only where **Browser sign-in** is on for the connector and the member's role allows it. Keep the two kinds of connection apart: | | Auto-connect (managed authorization) | Browser sign-in | | --------------------- | ----------------------------------------- | ----------------------------------------------------------------------- | | Sign-in | None; no consent screen | The member signs in to Ditto and approves the consent screen | | What it can reach | Your Ditto organization's main Space only | Whatever the member approves on their own Ditto account | | Who can switch it off | Your Ditto admins, for everyone at once | The member, by disconnecting Ditto in Claude or in their Ditto settings | Switching auto-connect off in Ditto, or removing a member from your Ditto organization, does not end a browser sign-in that member made with their own account. If members should reach only the organization Space through Claude, leave **Browser sign-in** off for Ditto and give their roles **Managed authorization**. ## Values you may be asked for | Field | Value | | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | MCP server URL | `https://api.heyditto.ai/mcp` | | Authorization server (issuer, and the assertion `aud`) | `https://api.heyditto.ai` | | Client ID | `https://claude.ai/oauth/mcp-oauth-client-metadata` | | Tenant ID (`aud_tenant`) | Shown on the Ditto **Claude auto-connect** page; only needed when several Ditto organizations trust one issuer. Claude-issued: enter it in Claude's **Tenant ID (optional)** field. Okta: your identity provider must send it as `aud_tenant`, or use a distinct issuer per Ditto organization | ## Troubleshooting Claude's connection test shows Ditto's answer. The common ones: | Ditto says | What to do | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `no Ditto workspace trusts this issuer` | Save the issuer URL in Ditto, exactly as Claude or your IdP shows it (trailing slash included), and make sure auto-connect is switched on. | | `more than one Ditto workspace trusts this issuer; set the tenant ID (aud_tenant)` | Claude-issued: enter the Ditto Tenant ID in Claude's **Tenant ID (optional)** field. Okta: Claude's field does not apply; configure Okta to send the Ditto Tenant ID as `aud_tenant` if it has a field for it, or give each Ditto organization a distinct trusted issuer (for example a separate Okta authorization server). | | `assertion iss is not this workspace's trusted issuer` | The Tenant ID names a Ditto organization that trusts a different issuer. Check both values. | | `no active member of this workspace has this verified email` | The person is not an active member of your Ditto organization, or has not verified their Ditto email, or (Claude-issued) their Claude email differs from their Ditto email. | | `client is not registered for enterprise managed auth` | Your identity provider stamps a different client ID. Use the client ID above. | | `the trusted issuer's signing keys could not be fetched` | Ditto could not read `/.well-known/openid-configuration`. Check the issuer URL. | | `assertion client_id does not match the requesting client` | (Okta) The Ditto app in Okta was registered with a different client ID. Use `https://claude.ai/oauth/mcp-oauth-client-metadata`, or rerun Claude's managed authorization setup. | | `assertion carries no email to find the member by` | (Okta) The assertion has no `email` claim. Ditto needs it for a member's first sign-in. | | `the identity provider marks this email as unverified` | (Okta) Okta sent `email_verified: false`. Verify the user's email in Okta. | | `this member is already linked to a different identity-provider subject` | (Okta) This Ditto member already signed in as another Okta user. Contact Ditto support to reset the link. | | `Claude auto-connect is not enabled for this workspace` | Auto-connect has not been enabled for your Ditto organization yet. Ask Ditto support (see **Availability**). | ## Turning it off Switch **Auto-connect members from Claude** off in the Ditto admin console. Every auto-connected session stops on its next request. Where **Browser sign-in** is on for the Ditto connector and the member's role allows it, Claude then asks members to connect Ditto themselves. To remove it on Claude's side as well, choose **Disable** under **Managed authorization** on the Ditto connector's **Configuration** tab.