An employee’s membership in a Claude organization—not an SSO or multifactor-authentication check—is what Claude verifies when issuing managed sign-ins to Atlassian. Superpower Daily’s documentation comparison finds that this path also matches accounts by email. Removing the employee stops new Claude-issued sign-ins, but does not establish when access already granted at Atlassian will end.
Original analysis: We compared five primary documents: Anthropic’s auto-connect guide, Atlassian’s implementation guide, two Okta guides and the Model Context Protocol’s Enterprise-Managed Authorization extension. We examined sign-in checks, account matching and offboarding, separating path-specific instructions from generic guidance. No authorization, account-linking or offboarding tests were performed. The requested cutoff was November 3, 2026, at 21:31:08 UTC. The supplied Anthropic snapshot was retrieved at 21:31:55.956 UTC, so exact equivalence to that cutoff is unverified. These findings concern documented commitments, not tested security.
First, choose who vouches for the employee
Atlassian’s setup guide offers two routes into tools including Jira and Confluence through its MCP server, the connection Claude uses to reach those tools. Under Claude-issued authorization, Atlassian trusts an organization-specific Claude issuer URL. Under Okta-managed authorization, it trusts the organization’s Okta tenant URL.
The choice changes setup responsibilities. Claude-issued authorization requires the Atlassian cloud ID in Claude’s Tenant ID field, but no Okta resource application. The Okta route puts Atlassian’s authorization-server URL and cloud ID into an Okta resource application, then connects Claude using managed authorization.
At sign-in, the checks diverge
Anthropic’s auto-connect guide makes the Claude-issued boundary explicit: Claude checks current organization membership, not single sign-on, multifactor authentication or the connector’s own sign-in rules. No identity provider or SSO is required, although Anthropic recommends enforcing SSO for the Claude organization. That recommendation does not mean the connector authorization itself performs those checks.
Okta’s agent-to-app guide instead requires SSO-capable requesting and resource applications. It describes assigning users or groups and configuring access scopes—the permissions an application can request. The MCP extension describes the identity provider evaluating groups, roles and conditional-access policies before issuing an authorization grant. Available controls do not establish which policies a particular organization has enabled.
Atlassian’s introduction broadly describes managed access as controlled by identity-provider policies, despite including the Claude-issued route without Okta. Anthropic’s path-specific explanation supplies the important qualification: Claude settings and connected-service permissions govern Claude-issued access. The introductory wording is not evidence that this route performs Okta policy checks.
Next, the service must find the right account
For Claude-issued access, the employee’s Claude email must match the connected-service account’s email. An unmatched employee sees the usual Connect prompt instead of an automatic connection. Anthropic says it sends both an email address and a unique identifier, but its stated matching requirement is email equality.
Okta’s generic validation guide uses a user’s subject identifier with issuer or tenant context for OpenID Connect integrations. For SAML, another single-sign-on standard, it uses issuer plus NameID, the user identifier supplied in that system. MCP recommends a stable subject identifier first, with email fallback for pre-existing accounts. These instructions cannot establish that Atlassian’s Okta implementation avoids email matching or email-reuse risks.
When the employee leaves, removal has several parts
- Remove the employee from the Claude organization. Anthropic says Claude then stops signing that person into connected services. This blocks future sign-ins rather than promising to cancel every authorization already issued.
- Verify removal from Claude’s member list. With SCIM directory synchronization, directory deletion removes the member from Claude; merely suspending them or marking them inactive does not.
- Remove the account from the connected service before reusing its email address. Anthropic warns that otherwise a replacement employee with that address could be signed into the former employee’s account.
Already-issued access is a separate clock
The strongest counterpoint is the centralized-revocation language. Anthropic says identity-provider deprovisioning removes connector access at the same time. The MCP extension says centralized revocation takes effect immediately across clients. But Anthropic also says existing sessions end when the connector’s access token expires or is revoked. Neither statement establishes immediate invalidation of already-issued Atlassian tokens.
The token exchange helps explain the distinction. The identity provider issues a grant called an ID-JAG, which Claude exchanges for an access token from the resource’s authorization server. Okta instructs implementers to issue short-lived access tokens without refresh tokens, requiring a new grant after expiry. Its example lifetime is not an Atlassian commitment.
Reader comments
Newest comments first. Replies stay oldest first.