# Single sign-on (SSO) in Amplitude

Source: https://amplitude.com/docs/admin/single-sign-on/sso

---

On this page

- [SSO basics](#sso-basics)
- [What your identity provider must send](#what-your-identity-provider-must-send)

# Single sign-on (SSO) in Amplitude

**Single sign-on** (SSO) is an authentication scheme that lets users use a single ID and password combination to log into multiple platforms, services, or systems. Amplitude supports SSO and is compatible with any SAML 2.0-compliant SSO provider, including:

- [Auth0](/docs/admin/single-sign-on/auth-0)
- [AWS IAM Identity Center](/docs/admin/single-sign-on/aws-iam-identity-center)
- [G Suite](/docs/admin/single-sign-on/g-suite)
- [Microsoft Azure Active Directory](/docs/admin/single-sign-on/azure-active-directory)
- [Okta](/docs/admin/single-sign-on/okta)
- [OneLogin](/docs/admin/single-sign-on/one-login)
- [Other](/docs/admin/single-sign-on/set-up-single-sign-on-sso-for-amplitude-using-another-service) providers not specifically named.

Follow the provider-specific guide for setup and configuration details.

## SSO basics

Before you enable SSO:

- You can **require** members of your organization to sign in with SSO. Requiring SSO prevents users from signing in with their email and password, so make sure your SSO system works before you turn it on in Amplitude.
- You can also **automatically** grant new users access to your organization through just-in-time provisioning. Amplitude only requires a new user to successfully authenticate with your identity provider. After Amplitude receives authentication, Amplitude adds the user to your organization. You can then configure roles for each new user to reflect their needs and the organization's needs.

Enterprise customers with access to project [permissions](/docs/admin/account-management/user-roles-permissions) can also choose the default project(s) that JIT-provisioned users will have access to.

## What your identity provider must send

When a user signs in through SSO, Amplitude looks for their email in the SAML assertion in this order:

1. The assertion subject.
2. An email claim attribute (`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`).
3. An `emailaddress` attribute (case insensitive).
4. An `email` attribute (case insensitive).

**If Amplitude can't find a valid email, the user can't sign in.** Most identity providers send the email by default. If yours doesn't, follow the provider-specific guide linked above to map the user's email into the assertion.

Was this helpful?

<!--$-->

<!--/$-->