> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackone.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Single Sign-On
> Let members sign in through your SAML identity provider, with domain verification and JIT provisioning.
StackOne Single Sign-On (SSO) lets your organization members sign in through your own SAML 2.0 identity provider (IdP). Once you connect an IdP and verify your email domain, any member whose work email is on that domain is sent to the IdP to authenticate instead of using a StackOne password.
Set this up in **Organization > Security > SSO** in the StackOne dashboard. You need the **Org Admin** role.
The **SSO** tab is enabled per organization. If you don't see it under **Organization > Security**, even as an Org Admin, contact StackOne support to turn it on.
## How SSO works
* StackOne acts as the SAML service provider (SP), and your IdP holds and authenticates the identities.
* Each organization has one SSO connection, bound to one email domain.
* Members with an email on your verified domain are redirected to your IdP when they sign in.
## Before you begin
Have these ready:
* The **Org Admin** role in your StackOne organization.
* Admin access to your SAML 2.0 IdP, such as Okta or Microsoft Entra ID.
* The ability to add a DNS TXT record for your email domain, which StackOne uses to verify ownership.
## Set up an SSO connection
On the **SSO** tab, select **Get started** to open the setup wizard. It opens in a side panel titled **Set up SSO** and collects your IdP's details in a few steps.
Select **Okta**, **Microsoft Entra ID**, or **Other SAML 2.0 provider**. Your choice tailors the field labels to match your IdP's console.
Enter a **Connection name** like `Acme Okta`, and the **Domain** your members' email addresses use, such as `acme.com`. Members with an email on this domain sign in through SSO.
StackOne shows an **ACS URL**, an **SP Entity ID**, and a **Default RelayState**. Copy them into your IdP's SAML application so it knows where to send assertions, how to identify StackOne, and where members land after an IdP-initiated sign-in.
Copy your IdP's **Entity ID (Issuer)**, **SSO URL (Entry Point)**, and **X.509 Certificate** back into StackOne. To fill all three at once, select **Upload SAML metadata file** and import the metadata your IdP generates.
Add the DNS TXT record StackOne generates to your domain, then verify it. Verification is what activates the connection.
Once registered, the connection is listed on the **SSO** tab with its **Connection**, **Domain**, and **Status** (Verified or Unverified). Select the connection to open its settings, where you can edit the SAML configuration, edit the domain, and verify it.
The exact clicks differ per IdP. Follow the guide for yours: [Okta](/identity/sso/okta), [Microsoft Entra ID](/identity/sso/microsoft-entra), or [any SAML 2.0 provider](/identity/sso/saml-generic).
## Verify your domain
Domain verification proves your organization owns the email domain on the connection. You add a TXT record that StackOne generates to your domain's DNS, and StackOne checks for it. Until the domain is verified, the connection is registered but inactive.
Verifying the domain unlocks three things:
* **SSO sign-in.** Members with an email on the domain are redirected to your IdP to authenticate.
* **Account linking.** An existing StackOne user whose email is on the domain is linked to the SSO connection, so they keep one account instead of a duplicate.
* **Trusted directory emails.** Emails provisioned through Directory Sync are treated as verified, so SSO can link those users when they first sign in.
## How members sign in
When a member signs in, they enter their email address on the StackOne sign-in page. If the email is on a verified SSO domain, StackOne redirects them to your IdP. After the IdP authenticates them, they return to StackOne signed in.
IdP-initiated sign-in also works. A member who opens the StackOne tile from your IdP lands on the StackOne dashboard already signed in. They still need organization membership from an invitation or Directory Sync. IdP-initiated sign-in authenticates them but doesn't place them in your organization.
## Just-in-time provisioning
The first time someone signs in through SSO without an existing StackOne account, StackOne creates their account automatically. This is just-in-time (JIT) provisioning, so you don't pre-create an account for every member.
With JIT enabled, that first sign-in also adds the person to your organization: at the organization role your identity provider asserts (**Viewer** by default, **Admin** on a fixed attribute) and to the connection's provisioned access, the projects you selected at the role you set for each. An invitation or Directory Sync still takes precedence over JIT.
See [Just-in-Time Provisioning](/identity/sso/jit-provisioning) to set the provisioned access and map the `stackone_role` attribute that grants organization admin.
JIT is turned on per connection with the **Enable JIT** action on the **Just-in-time provisioning** card of the **Provisioning** tab. With it off, SSO authenticates a member but organization membership comes from an invitation or Directory Sync.
## Require SSO
Once your connection is verified, you can require members to sign in through SSO and turn off email and password sign-in. Open **Organization > Security > Authentication**, edit the **Enforcement Policy**, and add your SAML connection to the **Enforced methods**.
You can only enforce a connection whose domain is verified. The **Enforcement Policy** won't let you save an unverified method, so a misfire there can't lock members out. It does not, though, check that sign-in actually works: a verified domain whose SAML app is misconfigured, your account isn't assigned to the app, or a certificate or issuer mismatch, still enforces, and enforcement disables password sign-in for everyone at once.
Before you enforce SSO, confirm sign-in works end to end. Open a private or incognito window and complete an SSO sign-in as a member who is assigned to the app in your IdP, not only your own account. Enforce only after that succeeds, because enforcing turns off password sign-in and anyone your IdP cannot authenticate is locked out.
Locked out after enforcing? An Org Admin who can still reach the dashboard can remove the method under the **Enforcement Policy** to restore password sign-in. If no one can get in, contact StackOne support.
## Next steps
Connect Okta as your SAML identity provider.
Connect Microsoft Entra ID (Azure AD) as your SAML identity provider.
Connect any identity provider that supports SAML 2.0.
Create members on first sign-in and map an attribute to organization admin.
Provision and deactivate members automatically from your IdP.
Grant many members the same project or account access at once.