# Organization-level SSO

Manage single sign-on (SSO) for all accounts within your organization.

If your business operates across multiple Stripe accounts and uses single sign-on (SSO) to authenticate users, you can centrally configure SSO with Stripe Organizations. You can add accounts that already have SSO configured to an organization, or configure SSO for all your accounts after you create an organization.

To set up SSO on Stripe for the first time, see [Single sign-on](https://docs.stripe.com/get-started/account/sso.md).

## Add accounts that you configured with SSO to an organization

If you have multiple accounts with SSO configured, you can’t preserve their individual SSO settings in your organization. You must [consolidate multiple authentication apps](https://docs.stripe.com/get-started/account/orgs/sso-consolidation.md) into a single authentication app for multiple accounts.

When you create your organization, Stripe consolidates the SSO settings of your accounts under your organization’s [single sign-on](https://dashboard.stripe.com/org/settings/security/sso) settings. This action updates the SSO settings in each individual account to read-only. You can still sign in to individual accounts, but you must edit settings such as verified domains and enforcement exclusively from the organization.

After setting up your organization with SSO, you can add accounts that share the organization’s SSO configuration. If your organization is set up with SSO set to **Optional**, you can also add accounts that don’t use SSO. You can’t add accounts that have separate SSO authentication.

## Configure SSO throughout an organization

Instead of setting up SSO separately in each account, you can centrally configure SSO throughout all accounts in your organization. Any organization-level verified domains or SSO configurations apply to all accounts within the organization.

### SSO settings for each domain

You can configure separate SSO settings for each verified domain or reuse the same SSO settings for multiple domains. For example, within the same organization, you can require SSO for one domain, set SSO to **Optional** for another, or disable it entirely to enable email and password sign-in.

### Multiple identity providers

Stripe supports multiple IdPs when each verified domain has only one IdP. For example, you can configure users with a `rocketrides.com` email address to authenticate with Okta and configure users with a `rocketdelivery.com` email address to authenticate with Entra ID.

> #### Account switching with multiple identity providers
> 
> When accounts under the same domain use the same identity provider, you can switch between them without re-authenticating. If your accounts use different identity providers, you must re-authenticate each time you switch.

## Assign account-level and organization-level roles

Organization-level SSO operates similarly to SSO in a single account. When Stripe receives a SAML assertion from an IdP, we examine the accounts and roles specified within it. Based on this information, Stripe assigns roles to the user. You can assign a single account-level role, a single organization-level role, or a combination of both account-level and organization-level roles.

When you assign these roles, use the `Stripe-Role-{account-id}` or `Stripe-Role-{org-id}` prefixes for the account and organization IDs, respectively. Stripe applies claims that include an account ID at the account level, and claims that include organization IDs at the organization level. Learn more about [account-level and organization-level roles](https://docs.stripe.com/get-started/account/orgs/team.md).

The following SAML assertion snippet makes three claims for the user:

1. In `acct_ONE`, the user is assigned the `developer` role.
2. In `acct_TWO`, the user is assigned the `developer` role.
3. In `org_ALPHA`, the user is assigned the `view_only` role.

As a result of these assertions, Stripe grants this user a session with the `developer` role in the `acct_ONE` and `acct_TWO` accounts. Stripe also assigns the `view_only` role in the `org_ALPHA` organization and all accounts within that organization:

```xml
<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Attribute Name="Stripe-Role-acct_ONE" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">developer</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute Name="Stripe-Role-acct_TWO" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">developer</saml2:AttributeValue>
  </saml2:Attribute>
  <saml2:Attribute Name="Stripe-Role-org_ALPHA" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">view_only</saml2:AttributeValue>
  </saml2:Attribute>
</saml2:AttributeStatement>
```
