How to Set Up SSO for Claude: Okta, Google Workspace, Entra ID, and OneLogin

The enterprise single sign-on market hit $5.48 billion in 2026, growing at 12.2% annually as organizations work to bring every SaaS tool under centralized identity governance. AI platforms are the newest category on that list. Claude now supports SAML-based SSO natively, which means employees authenticate with the same credentials they use for email, project management, and every other tool in the stack.

Claude SSO is available on three plan types: Team, Enterprise, and Console (the API platform). Once configured, users sign in through your identity provider instead of using email-based magic links. IT gets full control over who can access Claude and when access gets revoked.

The supported identity providers are Okta, Google Workspace, Microsoft Entra ID (formerly Azure AD), OneLogin, JumpCloud, and Duo. Anthropic handles the SAML integration through WorkOS, so the setup flow for every IdP follows the same pattern: verify your domain, create a SAML application in your IdP, exchange metadata with the WorkOS setup wizard, then enable SSO enforcement.

This guide covers the four most commonly deployed IdPs: Okta, Google Workspace, Entra ID, and OneLogin. Each walkthrough includes the exact configuration values and attribute mappings you need.

Before you touch your identity provider, two things need to happen in Claude's admin console: domain verification and parent organization setup. Skipping either one will block the SSO configuration flow entirely.

Domain verification requires adding a DNS TXT record to prove you own the email domain your employees use. Log into your Claude admin settings at claude.ai/admin-settings/identity for Team and Enterprise plans, or platform.claude.com/settings/identity for Console. Start the verification flow and the system will give you a TXT record value to add to your domain's DNS. Once the record propagates and Claude confirms it, your domain is locked to your parent organization. No other Claude organization can claim that domain after verification completes.

All verified domains must be managed through a single identity provider. If your company uses multiple email domains (like acme.com and acme.io), both need to be verified and both will use the same IdP.

Parent organizations are the container that holds your SSO configuration. Enterprise plans create one automatically. Team plans generate a parent organization when you first enable SSO. Console organizations need manual setup or an invitation to join an existing parent organization. The key constraint is that each parent organization links to exactly one identity provider. If you have multiple Claude organizations, say a Team plan for marketing and a Console org for engineering, they can share SSO settings by joining the same parent org, but they all must use the same IdP.

Before flipping the switch, communicate the timeline to your employees. Users with existing Free, Pro, or Max accounts on your verified domain will lose access to those personal accounts once you enable the "Require SSO for Claude" toggle. Their conversations are not deleted, but they cannot log in without going through your IdP. Give people a window to export any conversation history they want to keep. Schedule the cutover during a low-disruption period and make sure your IT team is ready to support questions on login day.

Every IdP setup follows the same core pattern: create a SAML application, enter the ACS URL and Entity ID from the WorkOS setup flow, map the email attribute, download the IdP metadata, and upload it back to WorkOS. The specifics vary by provider.

All configuration values, including the ACS URL, Entity ID, and SCIM credentials, come from the WorkOS setup wizard inside your Claude admin settings. Keep that page open in a separate tab while you work through your IdP configuration.

One constraint worth noting early: you cannot mix identity providers within a single parent organization. If your engineering team uses Okta and your marketing team uses Google Workspace, you need to standardize on one before starting the SAML setup. Organizations that tried to run parallel IdPs and merge later reported spending more time on migration cleanup than on the original SSO rollout.

Centralize your team's AI file outputs after SSO

Once your team authenticates through SSO, give them a shared workspace for everything Claude produces. 50GB free storage, no credit card, with built-in AI search and audit trails.

Sign Up Free

After SSO is active, you need to decide how user accounts get created in Claude. There are three options, and the right choice depends on your plan tier and how tightly you want to control access.

Invite-only is the most restrictive approach. An admin manually invites each user by email. The user still authenticates through SSO, but no account gets created until an admin sends the invitation. This works well for small teams or organizations that want to approve every seat individually. It is available on all plan types: Team, Enterprise, and Console.

Just-in-time (JIT) provisioning creates a Claude account automatically the first time someone authenticates through your IdP. If an employee with an email under your verified domain logs in via SSO and does not already have a Claude seat, JIT provisions one on the spot. This reduces admin overhead but means anyone in your IdP who can access the Claude SAML app will get a seat. JIT is also available on all plan types.

SCIM provisioning is the full lifecycle option. Your identity provider pushes user creation, updates, and deprovisioning events to Claude automatically. When you disable someone in Okta or Entra ID, their Claude access gets revoked without any manual intervention. SCIM is only available on Enterprise plans and eligible Console organizations. Team plans and Console orgs merged with Team plans cannot use SCIM.

For organizations above 50 users, SCIM is usually the right answer. It keeps Claude in sync with your identity provider and eliminates the need for ongoing manual seat management. For smaller teams, JIT provisioning with periodic access audits is typically sufficient.

If your team also uses workspace tools like Google Drive, Dropbox, or Fast.io for managing files that Claude agents produce, aligning your provisioning method across tools simplifies onboarding. When a new hire appears in your IdP, they get access to both the AI tools and the workspaces where those tools store their output.

Before you enforce SSO for your entire organization, test it with a single user account. Have someone who is assigned to the Claude app in your IdP navigate to claude.ai, enter their email, and confirm they get redirected to your identity provider's login page. After authenticating, they should land in your Claude organization's workspace.

If login fails, the most common cause is an email attribute mismatch. Install a SAML debugging browser extension like SAML-tracer and inspect the SAML response. Check the NameID and email claim values. They must contain an email address under your verified domain. Claude rejects email claims for unverified domains.

When both SAML and SCIM are configured, verify that both send the same email value. This is the single most frequent cause of "user is provisioned but can't log in" tickets. The correct field mappings by provider:

• Okta: both SAML and SCIM should map to user.email
• Google Workspace: both should use primaryEmail
• Microsoft Entra ID: both should use user.mail
• OneLogin: both should point to the same Email field

Certificate rotation is a maintenance task you need to plan for. The X.509 signing certificates that your IdP uses to sign SAML assertions have expiration dates. When a certificate expires, SSO breaks for everyone. Set a calendar reminder for 30 days before expiration, then update the certificate in the Metadata configuration section of your Claude identity settings.

After testing succeeds, enable the "Require SSO" toggle in your Claude admin settings. This disables email-based login for all users in your organization. The Primary Owner retains magic link access temporarily during initial setup, but you should migrate them to SSO as well. Test thoroughly before enforcing. A misconfigured SSO requirement with no fallback can lock your Primary Owner out of the admin console.

For organizations using Claude alongside persistent workspace tools, the SSO rollout is also a good time to standardize how your team stores and shares Claude's file outputs. Tools like Google Drive, S3, or Fast.io workspaces can serve as the collaboration layer where authenticated team members access what Claude produces. Fast.io's audit trail and granular permissions complement the identity governance SSO provides.