Single Sign-On (OIDC)

Single Sign-On (SSO) lets your team members authenticate to TrustComponent through your own identity provider. They sign in with their company email, complete authentication at your identity provider, and arrive in TrustComponent as fully signed-in users.

Availability

Single Sign-On is an add-on feature and is not enabled by default. To get it activated for your subscription, contact our team at mail@trustcomponent.com. Once activated, the Single Sign-On section appears under Governance in your subscription and you can create your first configuration.

How it works

SSO is built on standard OpenID Connect (OIDC) with the Authorization Code flow. Any OIDC-compatible identity provider works — Microsoft Entra ID, Google Workspace, Okta, Auth0, Keycloak, or a self-hosted server. Older protocols such as SAML, plain OAuth 2.0, the Implicit flow, the Device Code flow, and Resource Owner Password Credentials are not supported. If you need to integrate with one of these and OIDC is not an option for you, reach out at mail@trustcomponent.com — we can discuss alternatives.

A successful SSO sign-in goes through the following steps:

sequenceDiagram
    autonumber
    participant U as User
    participant TC as TrustComponent
    participant IdP as Your Identity Provider
    U->>TC: Opens /signin and enters work email
    TC->>TC: Lookup SSO config by email domain
    TC-->>U: Redirect to identity provider
    U->>IdP: Authenticate (password, MFA, ...)
    IdP-->>U: Redirect back with authorization code
    U->>TC: Callback at TrustComponent
    TC->>IdP: Exchange code for id_token + userinfo
    IdP-->>TC: id_token (email, name, sub, ...)
    TC->>TC: Resolve or create local user
    TC-->>U: Signed in — redirect to dashboard

A TrustComponent SSO configuration holds:

Identity provider settings — issuer URI, client ID, client secret, requested scopes, and a display name shown to end users.
Email domains — one or more domains whose users may sign in through this configuration. Each domain must be verified before it works.

Your subscription may host one or more SSO configurations — useful when you operate multiple identity providers, for example one for your own employees and one for an acquired company.

Users who sign in through SSO are connected to a regular TrustComponent user, so all existing roles, memberships, and data remain in place.

Identity provider client requirements

Before creating an SSO configuration in TrustComponent, register or open the client/application in your identity provider with the following settings.

Client type: confidential / web application. The client must support a client secret. Public clients (single-page applications without a secret) are not supported.

Authentication flow: Authorization Code (often labelled Standard Flow, Web Application Flow, or Server-side Web). We do not use the Implicit Flow, the Device Code Flow, or Resource Owner Password Credentials.

Valid redirect URI: https://id.trustcomponent.com/login/oauth2/code/<your-configuration-id>. The configuration ID is generated when you save the configuration on our side, so either come back to copy the exact value after saving, or — if your provider supports wildcards — register https://id.trustcomponent.com/login/oauth2/code/* up front.

Valid post-logout redirect URI: https://id.trustcomponent.com/logout-finish. Required so that we can sign the user out at your identity provider when they sign out of TrustComponent. Without it, the next sign-in silently picks up the still-open identity-provider session and the user appears unable to switch identities.

Scopes — your client must allow these scopes to be requested:

Scope	Required?	Why we use it
`openid`	Yes	OIDC contract — mandatory for every OIDC flow.
`email`	Yes	We use the identity-provider-supplied email to identify and link users. Sign-in is rejected without an email claim.
`profile`	Recommended	Provides the user’s given name and family name so we can pre-fill them on first sign-in. Without it, the user has to type their name during signup.

Claims we read

Claim	Required?	Used for
`sub`	Yes	Stable identifier for the user at the identity provider — used for every subsequent sign-in regardless of whether the email later changes. Provided by every OIDC-compliant provider out of the box.
`email`	Yes	Linking the sign-in to a local TrustComponent user; gated by the verified domain list. Sign-in is rejected if this claim is missing.
`given_name`, `family_name`	Recommended	Pre-fill the user’s profile on first sign-in. Without these, the user has to type their name on the signup form.

The default scopes in the creation form are openid, profile, email — adjust only if your provider names them differently.

Creating the SSO configuration

Open your subscription, go to Governance → Single Sign-On, and click Create. The form asks for the following fields.

Label — a short human-readable name, shown in lists and breadcrumbs. Example: Acme Corp Production.

Description (optional) — internal notes. Common uses: identity-provider tenant ID, name of the admin contact, why the configuration exists.

Initial domain — the first email domain your users will sign in with. After creation, it is awaiting verification and you’ll need to prove that you own it before sign-in works through this configuration; see Email domain verification below.

Provider display name — shown to end users on the redirect page (e.g. Microsoft Entra ID, Acme SSO, Company Login).

Issuer URI — the base URL of your identity provider realm/tenant from which <issuer>/.well-known/openid-configuration returns the OIDC discovery document. We discover all endpoints (authorize, token, JWKS, userinfo, end-session) from there, so make sure the discovery document is reachable. Examples: https://login.microsoftonline.com/<tenant-id>/v2.0 for Microsoft Entra, https://accounts.google.com for Google Workspace.

Client ID and Client Secret — the credentials issued by your identity provider for the client you set up in Identity provider client requirements.

Scopes — comma-separated list of scopes to request. Default is openid, profile, email.

Email domain verification

A TrustComponent SSO configuration only accepts sign-ins for users whose email belongs to one of its verified domains. This protects you from a misconfigured or compromised identity provider issuing tokens for domains it has no authority over — for example, blocking an external identity provider from claiming an email on a public webmail domain that you would not want federated. The verification proves to us that you control the domain and therefore your identity provider is authorized to vouch for identities within it.

Adding a domain. Open the SSO configuration details page and click Add domain. Enter the bare domain (e.g. acme.com, no protocol, no path). The domain is added as awaiting verification with a unique verification token.

DNS-TXT verification. Publish a TXT record on your DNS:

Name: _trustcaptcha-sso-verify.<your-domain> (e.g. _trustcaptcha-sso-verify.acme.com)
Value: the verification token shown next to the domain (starts with trustcaptcha-sso-verify=...)

TrustComponent polls pending domains automatically every few minutes and marks the domain as verified as soon as the TXT record is reachable. You can also press Verify manually on the configuration’s details page to force an immediate check.

Domain limit. By default each SSO configuration is limited to one verified domain. If you need more, reach out at mail@trustcomponent.com to have the limit raised.

When a user lands on the sign-in page and enters their work email, TrustComponent looks up the SSO configuration whose verified domains match the email’s domain, then redirects the browser to your identity provider for authentication. On callback, we map the identity-provider sign-in to a local TrustComponent user in one of three ways:

Returning sign-in. If we have already linked this user before, we sign in the existing local user immediately. This case intentionally does not re-check the email domain — trust was established at link time, and the email at the identity provider may legitimately change later (rename, re-brand, role change) without us locking the user out.
Email match for an existing user. If we don’t recognise the user yet, but their email belongs to an existing TrustComponent user, we connect the SSO sign-in to that user automatically. The user lands signed in. This is the typical path the first time a colleague signs in via SSO after the configuration was added to an existing team.
First-time signup. If neither of the above applies, the user lands on a short signup form pre-filled with the name and email supplied by the identity provider. The form is editable — for example, the user can adjust how their name should appear. After submit, a new TrustComponent user is created and connected to the identity provider.

Account switching. TrustComponent always tells the identity provider to prompt for fresh credentials with the entered email. A user who clicked “Sign in with SSO” is therefore always given a chance to authenticate as someone other than whoever is currently signed in to the identity provider in the same browser.

Sign-out. When a user signs out of TrustComponent, we also trigger a sign-out at your identity provider using its standard end-session endpoint (auto-discovered from the OIDC discovery document). If your identity provider does not expose an end-session endpoint, TrustComponent signs the user out locally only and the identity-provider session remains open.

SSO and local passwords

A TrustComponent user can authenticate by SSO, by local password, or by both. The two methods are independent and can coexist.

SSO-only users. When a user is created through first-time signup, no local password is set. They sign in exclusively through SSO.

Adding SSO to an existing password user. A user who originally signed up with a password automatically gets connected to SSO simply by signing in once via the SSO flow using the email that matches their existing TrustComponent account. The email-match case (described above) does the connecting.

Removing the SSO connection. A user can remove their SSO connection from their account at any time — but only if it is not their only sign-in method. If a user has no password and only one SSO connection, the unlink button is disabled; otherwise they would be locked out. The user can first add a password via the reset flow, then remove the SSO connection.

Multi-factor authentication. TrustComponent’s local multi-factor authentication (TOTP and WebAuthn / passkeys) is independent of the sign-in method. If a user has MFA enabled in their TrustComponent account, it is always required at sign-in — regardless of whether they authenticated through SSO or with a local password, and regardless of whether your identity provider already enforced MFA on its own.

Deleting an SSO configuration

There are two ways an SSO configuration can be removed: manually by a member of your team, or automatically after the subscription it belongs to is deleted and a 7-day grace period elapses.

Manual deletion

On the configuration’s details page, scroll to the Delete Single Sign-On section, type the configuration’s label to confirm, and click delete. The configuration and all its domains are removed.

All connections between TrustComponent users and this SSO configuration are detached as part of the deletion. The TrustComponent user accounts themselves are not deleted — only the SSO link. Consequences for affected users:

Users who also have a local password keep signing in as usual with email + password.
Users who relied exclusively on SSO for sign-in can recover access via the standard password reset flow with their email address. They receive a reset token, choose a password, and from then on sign in directly with TrustComponent.

Automatic deletion when the subscription is deleted

If the subscription this SSO configuration belongs to is deleted, the configuration enters a 7-day grace period. During this period the configuration still functions — existing users can still sign in — but it can no longer be managed from your TrustComponent dashboard, because the subscription it belonged to is gone.

If the grace period elapses without intervention, the configuration is deleted just as it would be on a manual deletion: all SSO connections are detached, the configuration and its domains are removed. Affected users follow the same recovery path described above.

Need help?

For anything that needs support, reach out at mail@trustcomponent.com. Common requests include:

Enabling SSO on a new or existing subscription.
Manually verifying a domain when DNS access is restricted.
Raising the domain limit for a configuration.
Restoring a configuration that is scheduled for automatic deletion.