Skip to main content
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) 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.
  • 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

1

Open the SSO settings

Go to Settings → Single Sign-On and choose a protocol: OIDC or SAML.
2

Register yield.xyz with your identity provider

yield.xyz shows the values your IdP needs before you enter anything back: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).
3

Enter your identity provider's details

  • Issuer URL
  • Client ID
  • Client Secret
4

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.
5

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.
6

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.

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.
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.

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

Single sign-on (SSO)

The full configuration model, including enforcement behavior.

Manage team roles

Invite the teammates who’ll sign in with SSO before you enforce it.