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, where your Claude organization’s settings allow it (see 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/<id> |
| 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 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
- In Claude, go to Organization 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. - On the connector’s Configuration tab, click Set up next to Managed authorization.
- On the Connect step, choose Claude-issued as the Identity source, and copy the Issuer URL Claude shows.
- In the Ditto admin console, 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.
- 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.
- Back in Claude, click Test connection. If it fails, see Troubleshooting.
- Click Enable and continue.
- 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
- 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.
- 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. - In the Ditto admin console, paste your Okta authorization server’s issuer into Trusted issuer URL, turn auto-connect on and click Save.
- In Claude, click Run test.
- 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.
- On the Scopes step, choose
mcp:readandmcp:write. These apply to every selected role. Ditto never grants an auto-connect session more than these two scopes, and gives Viewersmcp:readonly. - 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.
| 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 <iss>/.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 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 <issuer>/.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.