Single sign-on (SSO)

Configure OIDC or SAML 2.0 single sign-on so your team signs in to the dashboard through your identity provider.

SSO lets your team sign in to the yield.xyz dashboard through your own identity provider instead of email code login. It’s configured per team (not per project), and works with any OIDC-compliant or SAML 2.0-compliant identity provider; the dashboard includes setup hints for Google Workspace, Okta, and Azure AD (Entra ID) as examples, but no specific provider is required.

Configuration model

A team has at most one SSO configuration, with:

• Protocol: oidc or saml.
• Issuer, plus protocol-specific fields: clientId and a client secret for OIDC; an entryPoint (IdP SSO URL) and IdP certificate for SAML.
• Attribute mapping: which IdP claim maps to email (required), and optionally name, surname, and department. An optional group/role claim can be stored for future use; it is not used to assign dashboard roles today.
• Enabled: whether SSO login is available at all.
• Enforced: whether SSO is the only login method (see below).
• SSO login domain (optional): a single verified organization domain that lets members sign in via SSO without specifying a team ID. Consumer domains (for example gmail.com) are rejected.

Only the owner role can create, edit, or delete the SSO configuration. The admin role can view the current configuration read-only. Operator and member do not see the SSO settings page. See Roles and permissions.

Users must already exist on the team (invited from the dashboard) before they can sign in via SSO; there is no automatic account creation for users who only exist in the identity provider.

Enforcing SSO

With Enforced off, SSO is an additional login option alongside email code login. Turning Enforced on blocks email code login for the whole team: everyone must authenticate through the identity provider from then on.

Confirm every team member can sign in via SSO before enforcing it. Once enforced, email code login stops working for the entire team.

SSO exemption

A specific team member can be marked SSO-exempt, which lets that person keep signing in with email code login even while SSO is enforced for everyone else. This is set per member from the team page, not from the SSO settings page itself.

Who can toggle it depends on the target’s role: an owner can set it for any other member (never for themselves), and an admin can set it only for operators and members, never for another admin, an owner, or themselves.

What setup requires

SSO is configured in Settings → Single Sign-On in the dashboard. yield.xyz shows the values to register in your identity provider, and you enter your identity provider’s details in return:

Protocol	yield.xyz provides	You provide
OIDC	Redirect URI	Issuer URL, client ID, client secret
SAML	ACS URL, Entity ID	Issuer URL, entry point, IdP signing certificate

Save with SSO enabled but not enforced, confirm an SSO sign-in works, then turn enforcement on.

Next steps

Roles and permissions

Who can configure SSO.

Programmatic access

Automate project configuration with an Admin API key.