Anthropic Claude Enterprise SSO Integration Guide

What Claude Enterprise SSO Actually Covers

If you're searching for "Anthropic Claude Enterprise SSO integration," you're almost certainly trying to do one of two things: let your employees log into claude.ai or the Anthropic Console using your company identity provider, or figure out how SSO relates to programmatic API access for the apps your team is building. These are two different problems, and conflating them is the most common mistake teams make when rolling out Claude internally.

Claude Enterprise SSO is a SAML 2.0-based single sign-on integration that controls who can authenticate into Anthropic's hosted web products — the chat interface and, in some configurations, the Console used to manage an organization's Anthropic account. It does not generate API keys, does not control rate limits on the API, and does not give your developers a way to call Claude from code. For that, you still need separate API credentials, whether issued directly by Anthropic or distributed through a layer like SubToAPI that sits on top of your existing access.

How SAML SSO Works for Claude Enterprise

Anthropic's enterprise SSO follows the standard SAML 2.0 identity provider (IdP) flow used by most B2B SaaS products:

1. Your identity provider (Okta, Azure AD/Entra ID, OneLogin, Google Workspace, or any SAML 2.0-compliant IdP) acts as the source of truth for user identity.
2. Your Anthropic organization admin configures a SAML connection using metadata exchanged with the IdP — typically an entity ID, ACS URL, and signing certificate.
3. Employees hit claude.ai, get redirected to your IdP's login page, authenticate with existing corporate credentials (often with MFA already enforced by the IdP), and get redirected back into an authenticated Claude session.
4. User provisioning and deprovisioning can be tied to your IdP groups, so when someone leaves the company or changes roles, their Claude access is revoked automatically through your existing offboarding process.

This is valuable for security and compliance teams because it means Claude access inherits your organization's existing identity policies — password rotation, MFA, conditional access rules — instead of living as a separate set of credentials someone has to manage by hand.

Typical Setup Steps

While exact screens change over time, the general sequence for setting up SSO on an Anthropic Enterprise plan looks like this:

• Confirm your plan tier includes SSO (this is generally an Enterprise-tier feature, not available on individual or lower team tiers).
• Create a new SAML application in your IdP (Okta "SAML 2.0 App," Azure Entra "Enterprise Application," etc.).
• Exchange metadata: your IdP gives you an entity ID and SSO URL, Anthropic gives you an ACS URL and audience URI to plug into the IdP app.
• Map user attributes (email, first name, last name) between systems so provisioning works correctly.
• Test with a pilot group before enforcing SSO organization-wide, since a misconfigured mapping can lock out real users.
• Enforce SSO as the only login method once testing passes, disabling password-based login for your domain.

Why SSO Doesn't Solve Your API Access Problem

This is the part that trips teams up. You roll out SSO, your whole company can log into claude.ai with their Okta credentials, and then someone on the engineering team asks "great, how do I call this from my backend?" SSO has nothing to do with that question. SAML authenticates humans into a web session; it doesn't mint API keys, and Anthropic's API authentication model is separate from the Enterprise web product's login system.

If your actual goal is giving developers, internal tools, or customer-facing products access to Claude as an API — with streaming responses, tool use, and usage visibility — you need a different layer entirely. This is exactly the gap SubToAPI fills: it turns your existing Claude access into a proper HTTPS API with individual application keys (sub_live_...) per team member or per project, so you're not sharing one credential across a dozen scripts or trying to stretch SSO into something it isn't designed for.

A typical pattern looks like this once a developer has their key from the SubToAPI dashboard:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 1024,
    "messages": [
      { "role": "user", "content": "Summarize this incident report." }
    ]
  }'

Each engineer or service gets its own key, usage is tracked per key in the dashboard, and billing stays centralized under your team's plan instead of fragmenting into shadow API accounts that nobody tracks. That's the practical complement to SSO: SAML governs who can chat with Claude in the browser, and a key-management layer governs who can call Claude from code. See the quickstart and messages docs for the full request format, and the tools docs if you're wiring up function calling.

Rolling Out SSO Without Breaking Developer Workflows

A few practical notes if you're the person responsible for this rollout:

• Separate the chat rollout from the API rollout. Announce SSO as a login change for the web product specifically. Don't let people assume it affects how their scripts or internal tools authenticate.
• Audit existing shared API keys before and after SSO goes live. SSO enforcement is a natural moment to also clean up shared credentials sitting in .env files or Slack messages.
• Give developers a self-serve path for API keys. If the only way to get programmatic access is a ticket to IT, people will route around it with personal accounts. A dashboard where team members can generate their own scoped keys — with usage caps and visibility for admins — avoids that shadow-IT problem. Check pricing if you're evaluating per-seat options for a team.
• Document the distinction clearly in your internal wiki: "SSO = claude.ai login, API keys = building things." This single sentence prevents most support tickets.

questions

Does Claude Enterprise SSO give my application an API key automatically? No. SSO only authenticates users into Anthropic's web products (chat, Console). API access requires separate credentials issued through your API billing arrangement, whether direct from Anthropic or through a key-management layer like SubToAPI.

Which identity providers work with Claude Enterprise SSO? Any SAML 2.0-compliant IdP typically works, including Okta, Azure Entra ID (formerly Azure AD), OneLogin, and Google Workspace. Confirm current supported configurations with your Anthropic account team before rollout.

Can I enforce SSO for chat while still issuing separate API keys to developers? Yes, and this is the recommended setup. SSO governs human login to the web interface; API keys govern programmatic access. Keeping them as distinct systems — with per-developer keys tracked centrally — avoids both security gaps and billing confusion.