The Default Path
Most users simply enter their company email on the standard Invent sign-in page and are routed to SSO automatically when appropriate.Step 1: Enter Email
From the Invent sign-in page, the user types their company email (for example,alice@acme.com) and continues.
- Their domain is claimed and has enabled SSO profiles: Invent decides which login methods to offer, based on the access policy.
- Their domain is claimed but email-code sign-in is disabled: Invent routes them straight to the SSO picker.
- Their domain isn’t claimed: Invent falls back to the normal email-code login.
Step 2: Pick Your Provider
If the org has multiple SSO profiles enabled, the user picks which one to use. Each option shows the provider name you configured (e.g. “Acme Okta”) and the detected vendor with its logo.
Step 3: Authenticate at Your IdP
Invent redirects the user to your identity provider’s login page. They complete whatever your IdP requires, such as password, MFA, and conditional access.Step 4: Back to Invent
After successful authentication, the IdP redirects the user back to Invent’s OIDC callback URL. Invent exchanges the authorization code for an ID token, extracts the claims, and creates (or reuses) the Invent user. On success, the user lands on the dashboard. On failure, they see an error screen with the reason, including any error message forwarded from the IdP.The Explicit SSO Path
Users who know they should use SSO can also click the Use SSO instead link at the bottom of the sign-in page to skip straight to the dedicated SSO email-entry screen. From there they enter their company email and click Sign in with SSO.
What Happens Under the Hood
For the curious, here’s the full technical flow:Discover
POST /auth/sso/discover with the user’s email domain returns:- The list of enabled SSO profiles for the org that owns that domain
- Whether Google and email-code sign-in are currently allowed on that org
Start URL
Once the user picks a profile,
POST /auth/sso/{profile_id}/url returns a one-time authorization URL that points at the IdP, with a freshly-generated state and nonce.Redirect to IdP
The browser navigates to the IdP’s authorization URL. The IdP authenticates the user (password + MFA + whatever else your IdP enforces).
Callback
The IdP redirects back to
https://<your-hostname>/sign-in/oidc?code=...&state=.... Invent verifies the state, exchanges the code for tokens, and validates the ID token claims.User Resolution
Invent looks up the user by OIDC subject first, then by email. If no user exists and JIT provisioning is on, it creates a new user from the IdP claims. If the email matches a verified domain with auto-join on, the user is added as a member with the domain’s default role.
Session Created
A new Invent session is created, tagged with the SSO profile ID. If the org’s Access Policy sets a session TTL, the session expires after that window.
Profile Sync on Sign-In
If the user’s domain has profile sync on, every SSO sign-in refreshes their name, avatar, and email from the IdP’s ID token claims. This keeps Invent in sync with your directory as people get promoted, marry, or rebrand. Avatar handling is vendor-aware:- Google: uses
claims.picture(standard OIDC). - Microsoft Entra ID: never emits an avatar in the ID token. Entra users see no avatar sync (Entra photos live in Microsoft Graph, not in claims).
- Okta, Auth0, PingOne, Ping Identity, OneLogin, JumpCloud, Amazon Cognito, IBM Verify, Oracle IDCS, Cisco Duo: all use
claims.picture. - Generic OIDC / vanity domains: uses
claims.pictureif present.
First-Time Sign-In (JIT Provisioning)
When a user signs in through SSO and has no Invent account yet:- If the profile has JIT provisioning on, Invent creates the user automatically from the IdP claims.
- If the profile has JIT provisioning off, sign-in is rejected with “Automatic member provisioning is disabled for this SSO profile”.
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. Start over. |
| ”This SSO profile is not operational” | The profile was deleted or disabled between when the user started the flow and when they came back. |
| ”The identity provider rejected the credentials” | Your Client ID or Client Secret is wrong. Admin action required. |
| ”The sign-in attempt has expired or already been used” | OAuth invalid_grant. The auth code has already been exchanged. Ask them to sign in again. |
| ”The identity provider did not return an email address” | Your IdP’s OIDC app isn’t returning the email claim. Check your IdP’s scope/claim config. |
| ”The email is not on a domain claimed by this organization” | The user’s IdP account has an email outside your verified domains. Admin action required. |
| ”Google sign-in is not enabled for your domain, please use SSO instead” | Access policy blocks Google sign-in. Point the user at the SSO flow. |
| ”Email code sign-in is not enabled for your domain, please use SSO instead” | Access policy blocks email codes. Point the user at the SSO flow. |
/sign-in/oidc callback page with a clear message and a Go back button.
Sign-Out
Signing out of Invent ends the Invent session only. It does not sign the user out of your IdP. Dedicated controls to force re-authentication across your org are coming soon.Testing Your Setup
Before rolling SSO out to the whole team:- Create an SSO profile in Invent and save it.
- Verify the profile shows the right vendor badge (or at least a generic “OIDC” badge if you’re on a vanity domain).
- Open an incognito window and navigate to the Invent sign-in page.
- Enter your company email. Make sure the SSO option appears.
- Click Use SSO instead, enter your company email, and click Sign in with SSO to complete the IdP flow.
- Confirm you land on the dashboard.
- Check Settings → Audit Logs to see the SSO sign-in recorded.
- Sign out, sign back in, and verify repeat sign-ins are fast and don’t show any errors.