Claude API Single Sign-On Setup: A Practical Guide

Why "Claude API single sign-on" needs a definition first

If you searched for Claude API single sign-on setup, you probably ran into a confusing fact: the Claude API itself has no SSO. Every request to api.anthropic.com is authenticated with a static bearer token (sk-ant-...). There's no OAuth flow, no SAML assertion, no identity provider in the loop at request time. That's by design — the API is stateless, and bearer tokens are the simplest thing to put in a header.

What people actually mean by "SSO for Claude API" is usually one of two things:

1. Console-level SSO — logging into the Anthropic Console (where you manage billing and API keys) through your company's identity provider, available on Enterprise plans.
2. Application-level SSO — making sure that only employees authenticated through your company's IdP (Okta, Azure AD, Google Workspace) can trigger requests that eventually hit the Claude API, even though the API itself doesn't know who they are.

Most teams searching this term actually need #2: a way to gate access to Claude without every developer or employee holding a raw, unscoped API key. Here's how to build it.

Why you can't bolt SSO directly onto the API

The Claude API authenticates a request, not a person. There's no concept of a user session, no redirect-based login flow, and no per-user token exchange built into the API surface. If you want identity-aware access control, you have to build that layer yourself, in front of the API — or use a service that already has.

This isn't a limitation unique to Claude; it's how nearly every LLM provider's raw API works (OpenAI, Gemini, etc. are the same). SSO is an application-layer concern, not an API-layer one.

Option 1: SSO at the identity-provider level, API keys behind it

The most common pattern for teams is:

1. Users log into your internal tool or dashboard via SSO (OIDC/SAML through Okta, Azure AD, etc.).
2. Your backend verifies the identity token.
3. Your backend holds the actual Claude API key and makes the call on the user's behalf.
4. You log which authenticated user triggered which request for auditing.

A minimal Express middleware looks like this:

const { verifyOidcToken } = require('./auth');

app.use('/claude-proxy', async (req, res, next) => {
  try {
    const user = await verifyOidcToken(req.headers.authorization);
    req.user = user; // identity from your SSO provider
    next();
  } catch {
    res.status(401).json({ error: 'not authenticated' });
  }
});

app.post('/claude-proxy', async (req, res) => {
  const response = await fetch('https://api.anthropic.com/v1/messages', {
    method: 'POST',
    headers: {
      'x-api-key': process.env.ANTHROPIC_API_KEY,
      'anthropic-version': '2023-06-01',
      'content-type': 'application/json'
    },
    body: JSON.stringify({
      model: req.body.model,
      max_tokens: 1024,
      messages: req.body.messages
    })
  });
  const data = await response.json();
  console.log(`user=${req.user.email} tokens=${data.usage?.output_tokens}`);
  res.json(data);
});

This gives you SSO-controlled access without ever exposing the underlying API key to end users. The tradeoff: you're now maintaining an auth gateway, a proxy, logging, and rate limiting yourself.

Option 2: Skip the gateway, give each person their own scoped key

For smaller teams, building a full OIDC proxy is overkill. The pragmatic alternative is per-person API keys with centralized visibility — not SSO in the strict sense, but it solves the same underlying problem: knowing who used what, and being able to revoke access for one person without rotating a shared secret.

This is where SubToAPI fits. It turns your existing Claude access into application API keys (sub_live_...) that you issue per teammate from a dashboard, with usage metadata attached to each key:

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

Each teammate gets their own key under your Team or Scale plan, so when someone leaves, you revoke their key alone — no shared secret rotation, no proxy to maintain. It's not identity-provider SSO, but for most startups it replaces the reason people go looking for SSO in the first place: controlled, attributable, revocable access. See /pricing for seat-based plans and /docs/quickstart to get a key issued in minutes.

Option 3: Enterprise Console SSO (for Claude.ai/billing access)

If what you actually need is SSO for logging into the Anthropic Console itself — not API requests — that's handled on Anthropic's Enterprise plan through SAML with your IdP. This controls who can log in to manage billing, seats, and keys in the console UI. It does not change how the API authenticates requests; you'll still be working with bearer tokens for actual API calls. Don't confuse this with request-level authentication — they solve different problems.

A practical checklist

• Decide what you're actually protecting. Console access, API requests, or both?
• Never share one raw API key across a team. Use a proxy with per-user logging, or issue separate scoped keys.
• Log the identity next to the request, not just the token used — tokens get shared, identities (usually) don't.
• Rotate and revoke per-person, not globally, whenever someone leaves.
• Keep the SSO layer and the API layer separate in your mental model. One authenticates humans, the other authenticates requests.

Read /docs for authentication details if you go the managed-key route, or /docs/streaming and /docs/tools once you're past the setup stage and building the actual integration.

questions

Does the Claude API support SAML or OAuth natively? No. API requests are authenticated with a static bearer token. SAML/OAuth SSO exists only for logging into the Anthropic Console on Enterprise plans, not for individual API calls.

How do I stop every employee from needing the raw API key? Put a thin backend or proxy in front of the API that checks your SSO/IdP session before forwarding requests, or issue each person a separate scoped key through a key-management layer like SubToAPI.

Is per-user API key management a real alternative to SSO? For access control and auditing purposes, yes. It won't give you SAML login flows, but it solves the practical problem most teams have: knowing who used the API and revoking access per person without rotating a shared secret.