> ## Documentation Index
> Fetch the complete documentation index at: https://yieldxyz.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up SSO

> Configure OIDC or SAML in the dashboard, register it with your identity provider, verify sign-in, then enforce it.

Configure single sign-on for your team, verify it works, then make it the only way in. This guide covers the setup workflow. See [Single sign-on (SSO)](/documentation/advanced-setup/sso) for the configuration model and what enforcement changes.

## Prerequisites

* The **owner** role. Owners are the only role that can create, edit, or delete the SSO configuration; **admin** can view it read-only; operator and member don't see the settings page. See [Roles and permissions](/documentation/advanced-setup/roles-permissions).
* The teammates who'll use SSO must already be invited to the team from the dashboard. SSO does not create accounts for people who only exist in the identity provider.
* Admin access to your identity provider (Google Workspace, Okta, Azure AD/Entra ID, or any other OIDC or SAML 2.0 provider).

## Configure and register

<Steps>
  <Step title="Open the SSO settings">
    Go to **Settings → Single Sign-On** and choose a protocol: **OIDC** or **SAML**.
  </Step>

  <Step title="Register yield.xyz with your identity provider">
    yield.xyz shows the values your IdP needs before you enter anything back:

    | Protocol | yield.xyz shows | Register it as |
    | - | - | - |
    | OIDC | Redirect URI | Your OAuth app's authorized redirect URI |
    | SAML | ACS URL (Callback URL), Entity ID (SP Issuer) | Your IdP app's ACS/SSO URL and SP Entity ID |

    For SAML, the setup screen also shows the fixed Name ID format (`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`) and collapsible setup hints for Google Workspace, Okta, and Azure AD (Entra ID).
  </Step>

  <Step title="Enter your identity provider's details">
    <Tabs>
      <Tab title="OIDC">
        * **Issuer URL**
        * **Client ID**
        * **Client Secret**
      </Tab>

      <Tab title="SAML">
        * **Issuer URL** (IdP Entity ID)
        * **Entry Point** (IdP SSO URL)
        * **IdP Certificate**, the IdP's public signing certificate in PEM format
      </Tab>
    </Tabs>
  </Step>

  <Step title="Set attribute mapping">
    Expand **Show attribute mapping** and map the IdP claim that carries each value:

    * **Email claim** (required)
    * Name, surname, and department claims (optional)
    * An optional IdP/future groups claim, stored for later use; it does not assign a dashboard role today

    Turn on **Refresh name, surname, and department from the IdP on each SSO login** if you want those fields kept in sync on every sign-in; email is never updated this way.
  </Step>

  <Step title="Optionally set an SSO login domain">
    Enter a single verified organization domain (for example `yield.xyz`) so members with an email at that domain can start SSO without a team-specific link. Consumer domains are rejected. Leave it blank to require the team-specific sign-in link instead.
  </Step>

  <Step title="Save with Enabled on and Enforced off">
    Leave **Enforced** off for now, so SSO is an additional login option alongside email code login while you verify it. Save.
  </Step>
</Steps>

## Test sign-in

Before enforcing anything, confirm SSO actually works. From the dashboard's sign-in page, use **Continue with SSO** (with an email at your configured domain, or your team's SSO link) and complete the identity provider's flow. Have at least one other invited teammate do the same.

<Warning>
  Confirm every current team member can sign in via SSO before enforcing it. Once enforced, email code login stops working for the whole team. Keep your current dashboard session open until you have set a break-glass exemption.
</Warning>

## Enforce

Return to **Settings → Single Sign-On** and turn **Enforced** on. Email code login stops working immediately for everyone except an exempted account.

## Set a break-glass exemption

Immediately after enforcing, while you are still signed in, exempt at least one account so it can still sign in with email code login if the identity provider is ever unreachable. From the **Team** page, open a member's row actions and choose **Exempt from SSO**.

Who can toggle it depends on the target's role: an owner can exempt any other member (never themselves); an admin can exempt only operators and members, never another admin, an owner, or themselves. An exempted member shows an **SSO exempt** label on the team page. The action only appears once SSO is enforced, which is why this step comes after enforcement.

## Verify

* Sign out and sign back in with **Continue with SSO** to confirm enforcement took effect.
* Confirm the exempted account can still sign in with an email code.
* An **admin** can open **Settings → Single Sign-On** and see the configuration and its Enabled/Enforced state, read-only.

## Next steps

<Columns cols={2}>
  <Card title="Single sign-on (SSO)" icon="right-to-bracket" href="/documentation/advanced-setup/sso">
    The full configuration model, including enforcement behavior.
  </Card>

  <Card title="Manage team roles" icon="user-shield" href="/guides/enterprise/rbac">
    Invite the teammates who'll sign in with SSO before you enforce it.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.