> ## 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.
# Profiles
> Connect your identity provider to Invent via OpenID Connect (OIDC)
SSO Profiles require a **Business** or **Enterprise** plan. [View plans](/guides/pricing-and-plans)
An **SSO Profile** is a connection between Invent and one of your identity providers. Invent implements standards-compliant **OpenID Connect (OIDC)**, so any OIDC-capable identity provider can be used, including Okta, Microsoft Entra ID, Google Workspace, Auth0, PingOne, OneLogin, JumpCloud, and others.
An organization may have multiple profiles (for example, one profile for full-time employees on Entra ID and another for contractors on Auth0). At sign-in time, every user whose email matches a [verified domain](/workspace-management/sso/domains) on the organization will see all **enabled** profiles in the provider picker and may choose between them.
## The Profiles Table
| Column | Description |
| ------------ | ------------------------------------------------------------------------------------------- |
| **Name** | The display name you assigned to this profile (for example, "Acme Okta"). |
| **Provider** | A vendor badge, auto-detected from the Issuer URI. Falls back to a generic "OIDC" badge. |
| **Enabled** | A toggle. When off, the profile is hidden from the sign-in picker and rejects new sign-ins. |
| **Actions** | ✏️ Edit • 🗑️ Delete |
## Before You Start
Two prerequisites must be prepared **before** creating a profile inside Invent:
1. **An OIDC application inside your identity provider** (Okta, Entra ID, or another supported vendor). After creating it, you will receive three values:
* **Issuer URI**: the base address of your identity provider with no path (for example, `https://acme.okta.com`).
* **Client ID**: the public identifier of the OIDC application.
* **Client Secret**: the secret credential of the OIDC application. Treat this like a password.
2. **Invent's redirect URIs registered on the OIDC application**. See the section below for where to find them.
### Redirect URIs
Your identity provider needs to know which URLs it is allowed to redirect users to after they authenticate. In Invent, click the **🔗 Redirect URIs** button at the top of the Identity Providers section to open a dialog listing every redirect URI that applies to your workspace.
Every redirect URI in the dialog follows this pattern:
```
https:///sign-in/oidc
```
The default Invent domain is always listed. Every [custom domain](/workspace-management/white-label#domain) you have added for whitelabeling is also listed, each with its own `/sign-in/oidc` redirect URI. Invent generates and accepts these redirect URIs dynamically on all of your hostnames, so no additional configuration is required on the Invent side.
On the identity-provider side, you can register as many or as few of these redirect URIs as you like:
* **Register all of them** for maximum flexibility. Users will be able to complete the sign-in flow from any of your Invent hostnames, including any new custom domains you add later.
* **Register only one** if you want to lock sign-in to a single whitelisted hostname, for example your primary whitelabel domain.
Some identity providers only allow a single redirect URI per OIDC application. This is a limitation of the identity provider, not of Invent. If yours is one of them, pick the hostname your users will sign in through and register only that URI.
Copy each URI individually and paste it into your identity provider's list of allowed redirect URIs. This field is sometimes labeled **Sign-in Redirect URIs** or **Reply URLs** depending on the vendor. If you add a new custom domain later and want users to be able to sign in from it, reopen this dialog, copy the new URI, and register it in your identity provider as well.
The **Manage domains** button inside the Redirect URIs dialog navigates directly to [Settings → Domains](/workspace-management/white-label#domain), where custom domains are added. Once a new custom domain is verified, it is automatically added to this dialog as a new redirect URI on your next visit.
## Creating a Profile
1. Go to **Settings** → **SSO** → **Identity Providers**.
2. Click **Add OIDC**.
3. Fill in the form:
* **Display name**: the label shown in the provider picker on the sign-in page (for example, "Acme Okta").
* **Domain, Issuer URI, or Well-Known URL**: the base Issuer URI of your identity provider. The full `.well-known/openid-configuration` URL can also be pasted here; Invent will strip the well-known suffix automatically and upgrade `http://` to `https://` before storing it.
* **Client ID**: from your identity provider's OIDC application.
* **Client Secret**: from your identity provider's OIDC application. The value is encrypted at rest and is never returned in API responses.
4. Click **Create**.
Invent validates the Issuer URI during creation by fetching the OIDC discovery document from `/.well-known/openid-configuration`. If the resolved URL is incorrect, unreachable, or does not return a valid OIDC metadata document, creation fails with an error and no profile is stored.
New profiles are created **enabled** by default. They become available in the sign-in picker the moment they are saved, provided at least one verified domain exists on the organization.
### Issuer URI Examples
| IdP | Issuer URI format |
| ----------------------- | ------------------------------------------------------- |
| **Okta** | `https://acme.okta.com` |
| **Microsoft Entra ID** | `https://login.microsoftonline.com//v2.0` |
| **Google Workspace** | `https://accounts.google.com` |
| **Auth0** | `https://acme.auth0.com` |
| **PingOne** | `https://auth.pingone.com//as` |
| **OneLogin** | `https://acme.onelogin.com/oidc/2` |
| **JumpCloud** | `https://oauth.id.jumpcloud.com/` |
| **Amazon Cognito** | `https://cognito-idp..amazonaws.com/` |
| **IBM Security Verify** | `https://.verify.ibm.com/oidc/endpoint/default` |
| **Oracle IDCS** | `https://.identity.oraclecloud.com` |
| **Cisco Duo** | `https://.duosecurity.com` |
Invent auto-detects these vendors from the hostname of the Issuer URI and displays the matching logo and name inside the provider picker. Any other OIDC provider is fully supported and displays as a generic "OIDC" profile.
### OIDC Scopes
Invent requests three standard OIDC scopes from your identity provider: `openid`, `email`, and `profile`. No special configuration is required on the identity-provider side, as these scopes are part of the OIDC core specification and are supported by every OIDC-compliant provider by default.
## Editing a Profile
Click the **✏️ Edit** icon on any profile row to open the Edit OIDC Provider dialog.
The following fields can be updated:
* **Display name**.
* **Issuer URI** and **Client ID**, which may need to change when the OIDC application is rotated or recreated inside your identity provider.
* **Client Secret**. Leave the field blank to keep the existing secret unchanged. Enter a new value to rotate the secret; the previous value is replaced atomically and cannot be recovered.
The **provider type** (OIDC) cannot be changed on an existing profile. If a different protocol or provider type is required in the future, delete this profile and create a new one.
## Enabling and Disabling Profiles
The **Enabled** toggle on each profile row lets you pause a profile without deleting its configuration.
When a profile is disabled:
* It is hidden from the provider picker on the sign-in page.
* Any OIDC callback still in flight for that profile is rejected with a "not operational" error.
* Existing sessions created through the profile are preserved and are **not** revoked.
* All configuration, including the encrypted client secret, is retained so the profile can be re-enabled immediately without re-entering any values.
This is the recommended way to stage changes safely, for example while rotating an OIDC application in your identity provider or pausing access to a contractor-only profile.
## Deleting a Profile
Click the **🗑️ Delete** icon on a profile row to remove it. Deletion is protected by a confirmation dialog that reports the number of active SSO sessions the profile currently owns, so you can gauge the impact before confirming.
Deleting a profile has the following effects:
* **All SSO sessions created through this profile are revoked in the same database transaction.** Users currently signed in through this identity provider are signed out immediately and must re-authenticate on their next request.
* The deletion is permanent. The profile configuration, including the encrypted client secret, is removed from storage and cannot be recovered.
* User accounts and organization memberships are **not** affected. Users who had signed in through this profile can still sign in through another enabled SSO profile, or through Google or email-code sign-in if the [Access Policy](/workspace-management/sso/access-policy) allows it.
## Just-in-Time (JIT) Provisioning
When a user signs in through SSO for the first time and no matching Invent account exists, the profile's JIT setting determines what happens next:
* **JIT enabled** (default). Invent creates the user automatically from the claims returned by the identity provider. Combined with **Auto-Join** on the matching [verified domain](/workspace-management/sso/domains#auto-join), this is the fastest way to onboard a team at scale. Users never need to be invited manually.
* **JIT disabled**. First-time SSO sign-ins are rejected with the message *"Automatic member provisioning is disabled for this SSO profile, please ask an admin to invite you first."* Use this setting when you require explicit control over which users are provisioned, for example in highly regulated environments.
JIT is configured per profile and defaults to **on** when a new profile is created.
## Revoking Sessions
Dedicated session revocation controls (a sessions table with per-user sign-out and an organization-wide "sign out everyone" action) are **coming soon**. For now, the only way to forcibly revoke the SSO sessions created through a specific profile is to delete the profile itself. Deletion revokes every session owned by the profile in the same transaction.
## Vendor Detection
Invent recognizes popular identity providers from the hostname of the Issuer URI and automatically displays the matching vendor name and logo in the provider picker. Vendor detection is **display-only**. The underlying authentication pipeline is standards-compliant OIDC regardless of which vendor is detected, or whether any vendor is detected at all.
Supported vendors:
| Vendor | Matches on hostname |
| ------------------- | ---------------------------------------------------- |
| Microsoft Entra ID | `login.microsoftonline.com` |
| Google | `accounts.google.com` |
| Okta | `*.okta.com`, `*.oktapreview.com` |
| Auth0 | `*.auth0.com` |
| PingOne | `*.pingone.com` |
| Ping Identity | `*.pingidentity.com` |
| OneLogin | `*.onelogin.com` |
| JumpCloud | `*.jumpcloud.com` |
| Amazon Cognito | `*.amazoncognito.com`, `cognito-idp.*.amazonaws.com` |
| IBM Security Verify | `*.appid.cloud.ibm.com`, `*.verify.ibm.com` |
| Oracle IDCS | `*.identity.oraclecloud.com` |
| Cisco Duo | `*.duosecurity.com` |
If your identity provider is reachable on a **vanity domain** (for example, Okta configured at `auth.acme.com`), the profile still works exactly as any other OIDC profile. It simply displays as a generic OIDC connection without a vendor logo, since hostname-based detection cannot associate a custom domain with a specific vendor.
## Security
* **Client secrets are encrypted at rest** using Invent's secret-management subsystem and are never transmitted outside the backend in plaintext. Both the Invent UI and the public API read from a sanitized configuration view that omits the secret entirely.
* **OIDC discovery documents are cached** for up to 10 minutes. When the Issuer URI on a profile is changed, the cache entry for that profile is invalidated automatically so the next sign-in uses the new metadata.
* **Email verification is enforced**. If your identity provider returns `email_verified: false` in the ID token, Invent rejects the sign-in and surfaces a clear error to the user asking them to verify their email with the identity provider.
* **Fallback from `email` to `preferred_username`**. Some Microsoft Entra ID tenants do not emit the standard `email` claim in ID tokens. When `email` is missing, Invent falls back to `preferred_username` (which Entra formats as a UPN email) so sign-in succeeds without configuration changes on the identity provider.
## Troubleshooting
Invent was unable to fetch the `.well-known/openid-configuration` document from the Issuer URI provided on the profile. Verify that the URL resolved from the Issuer URI is correct, publicly reachable from the internet, and served over HTTPS. Identity providers hosted on private networks or behind a VPN are not supported.
The OIDC `invalid_client` error typically indicates that the Client ID or Client Secret on the profile does not match the values configured on the OIDC application inside your identity provider. This often happens after a secret rotation. Open the profile's **Edit** dialog and re-enter both values.
This error corresponds to the OIDC `invalid_grant` response. Every sign-in attempt is single-use and valid for **10 minutes** from the moment the authorization URL is generated. Ask the user to return to the [Invent sign-in page](https://useinvent.com/sign-in) and start the flow again.
SSO sign-in is restricted to users whose email matches a [verified domain](/workspace-management/sso/domains) on the same organization that owns the SSO profile. Either add the user's domain to the organization's list of SSO domains, or have them sign in with an email address on an already-verified domain.
The identity provider returned `email_verified: false` in the ID token. Have the user complete email verification inside the identity provider, or adjust the identity-provider claim configuration so that verified emails are the only ones surfaced to Invent.
JIT provisioning is disabled on this profile and the user does not yet have an Invent account. Either invite the user to your organization manually before they sign in, or enable JIT on the profile.