> ## Documentation Index > Fetch the complete documentation index at: https://docs.useinvent.com/llms.txt > Use this file to discover all available pages before exploring further. # Sign-In Flow > What your team sees when signing in through SSO Once you've [verified a domain](/workspace-management/sso/domains) and [added an SSO profile](/workspace-management/sso/profiles), your team can sign in through your identity provider. This page walks through what that looks like end-to-end. ## The Default Path Most users simply enter their company email on the standard [Invent sign-in page](https://useinvent.com/sign-in) and are automatically routed to SSO when appropriate, without ever having to make an explicit choice. ### Step 1: Enter Email From the [Invent sign-in page](https://useinvent.com/sign-in), the user enters their company email address (for example, `alice@acme.com`) and clicks continue. Sign-in email entry Behind the scenes, Invent checks the user's email domain against the list of claimed SSO domains across all organizations and decides what to do based on the owning organization's [Access Policy](/workspace-management/sso/access-policy). The email field **prefers email code**. Clicking **Continue** from this field sends a one-time code to the user's inbox in every case except one: when email-code sign-in is disabled on the Access Policy and the organization has at least one enabled SSO profile. The full decision matrix is: | Email domain | SSO profile enabled | Email code allowed | What happens on Continue | | ------------ | :-----------------: | :----------------: | -------------------------------------------- | | Not claimed | Any | Any | Send a one-time code | | Claimed | No | Yes | Send a one-time code | | Claimed | Yes | Yes | Send a one-time code | | Claimed | Yes | No | Redirect directly to the SSO provider picker | If the user wants to authenticate through SSO while email-code sign-in is still enabled on their domain, they must click the **Use SSO instead** link below the email field. The email field itself only diverts to SSO when email-code sign-in is disabled and at least one SSO profile is available, which is the scenario where the Access Policy has effectively made SSO mandatory. ### Step 2: Pick Your Provider If the organization has multiple enabled SSO profiles, the user is shown a picker and selects which one to use. Each option displays the profile's configured display name (for example, "Acme Okta") alongside the auto-detected vendor logo, when available. SSO provider picker If only one profile is enabled, the picker is skipped and the user is redirected directly to the identity provider. ### Step 3: Authenticate at Your Identity Provider Invent redirects the user to the identity provider's login page. The user completes whatever authentication steps the identity provider requires, such as password entry, multi-factor authentication, or conditional-access checks. Invent has no visibility into or control over this step. ### Step 4: Back to Invent After successful authentication, the identity provider redirects the user back to Invent's OIDC callback URL at `/sign-in/oidc`. Invent verifies the callback's `state` parameter, exchanges the authorization code for an ID token, validates the claims inside the token, and then creates or reuses the Invent user account. On success, the user is taken to the dashboard. On failure, the user is shown an error screen that explains the reason, including any error code and description forwarded from the identity provider. ## The Explicit SSO Path Users who already know they should authenticate through SSO can click the **Use SSO instead** link at the bottom of the [Invent sign-in page](https://useinvent.com/sign-in). This skips the default email-code path and takes them directly to a dedicated SSO email-entry screen. From there, they enter their company email and click **Sign in with SSO**. Dedicated Sign in with SSO screen The screen prompts them to enter their company email and then follows the same **pick your provider → authenticate → back to Invent** sequence as the default path. ## Profile Sync on Sign-In If the user's matching domain has [Sync Profile](/workspace-management/sso/domains#sync-profile) enabled, every SSO sign-in refreshes the user's name, avatar, and email from the ID token claims returned by the identity provider. This keeps Invent's view of each user consistent with your directory of record over time, even as employees are given new names, update their photos, or have their email addresses reassigned. Avatar handling is vendor-aware because different identity providers expose profile photos through different mechanisms: * **Google**: uses the standard OIDC `picture` claim. * **Microsoft Entra ID**: does not emit a profile photo in the ID token. Entra ID profile photos are only accessible through Microsoft Graph, so avatar sync is effectively disabled for Entra users. * **Okta, Auth0, PingOne, Ping Identity, OneLogin, JumpCloud, Amazon Cognito, IBM Security Verify, Oracle IDCS, Cisco Duo**: all use the standard OIDC `picture` claim. * **Generic OIDC providers and vanity domains**: use the standard OIDC `picture` claim when it is present in the ID token. ## First-Time Sign-In (JIT Provisioning) When a user signs in through SSO and does not yet have an Invent account, the profile's JIT setting determines the outcome: * If the profile has **JIT provisioning enabled**, Invent creates the user automatically from the identity-provider claims and continues the sign-in. * If the profile has **JIT provisioning disabled**, the sign-in is rejected with the message *"Automatic member provisioning is disabled for this SSO profile, please ask an admin to invite you first."* If JIT creates the user **and** the user's email matches a verified domain with **Auto-Join** enabled, the new user is also added as a member of your organization with the domain's configured default role. This combination is what allows a new hire to go from "never heard of Invent" to "signed in with the right role" in a single click. ## Errors Your Users Might See | Error message | What it means | | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | "Your SSO sign-in session expired or was invalid" | The `state` token was missing, tampered with, or older than 10 minutes. The user needs to restart the sign-in flow from the beginning. | | "This SSO profile is not operational" | The profile was deleted or disabled between the moment the user started the flow and the moment the identity provider redirected them back. | | "The identity provider rejected the credentials" | The identity provider returned `invalid_client`. The Client ID or Client Secret on the profile is wrong, or the secret was rotated. Requires admin action on the profile. | | "The sign-in attempt has expired or already been used" | The identity provider returned `invalid_grant`. The authorization code has already been exchanged, or more than 10 minutes have passed. Ask the user to sign in again. | | "The identity provider did not return an email address" | The OIDC application on the identity provider is not configured to emit the `email` claim. Review the scope and claim configuration on the identity provider. | | "The email is not on a domain claimed by this organization" | The identity-provider account is associated with an email address that does not match any verified domain on your organization. Claim the user's domain, or use a different email. | | "Google sign-in is not enabled for your domain, please use SSO instead" | The organization's Access Policy has disabled Google sign-in for users on verified domains. Direct the user to the SSO flow instead. | | "Email code sign-in is not enabled for your domain, please use SSO instead" | The organization's Access Policy has disabled email-code sign-in for users on verified domains. Direct the user to the SSO flow instead. | Most of these errors surface on the `/sign-in/oidc` callback page with a clear explanation and a **Go back** button that returns the user to the sign-in page. ## Sign-Out Signing out of Invent terminates the Invent session only. It does **not** sign the user out of the identity provider, because OIDC single-logout is out of scope for the current release. If the user returns to Invent and clicks sign in again, the identity provider may authenticate them silently from its own session. Dedicated controls for forcing re-authentication across your organization are [coming soon](/workspace-management/sso/profiles#revoking-sessions). ## Testing Your Setup Before rolling SSO out to the entire team, perform an end-to-end test using an admin account: 1. Create an SSO profile in Invent and save it. 2. Verify that the profile displays the correct vendor badge in the profiles table, or the generic "OIDC" badge if the profile uses a vanity domain. 3. Open an **incognito window** (so existing sessions do not interfere) and navigate to the [Invent sign-in page](https://useinvent.com/sign-in). 4. Enter your company email and confirm that the SSO option is presented. 5. Click **Use SSO instead**, enter your company email, and click **Sign in with SSO** to exercise the full identity-provider flow. 6. Confirm that the sign-in completes successfully and that you land on the Invent dashboard. 7. Open **Settings → Audit Logs** and confirm that the SSO sign-in event has been recorded. 8. Sign out, then sign in a second time, and confirm that repeat sign-ins complete without errors. Once the end-to-end flow is verified, you can safely enable auto-join on the domain and tighten the [Access Policy](/workspace-management/sso/access-policy) at your own pace.