Single Sign-On (OIDC & SAML)

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.

TrustComponent supports both common standards: OpenID Connect (OIDC) and SAML 2.0.

Single sign-on is available for projects and agencies alike. You find it under Governance › Single Sign-On in either of them:

How many configurations you can create depends on your plan and add-ons — see Current add-ons. The page shows the limit next to New SSO Configuration; without one, it shows Not included · See options.

Both protocols lead to the same result: members sign in with their company account, their email domain must be verified, and your local TrustComponent settings such as multi-factor authentication stay in force.

You can switch the protocol at any time in the first step of the setup guide. A switch removes the identity provider settings of the previous protocol, so sign-in stops until you connect your identity provider again; linked members are linked again automatically on their next sign-in.

1. Create the configuration. Open your project or agency, go to Governance › Single Sign-On and choose New SSO Configuration. Pick a label, the identity provider name your members see on the sign-in redirect, and your email domain.

2. Follow the setup guide. The configuration page opens with a setup guide. Choose the protocol and your identity provider, and the guide shows the exact steps, including the service provider details to copy into your identity provider. These values contain the ID of your configuration, which is why they exist only after step 1.

3. Connect your identity provider. Enter the client credentials (OIDC) or the metadata URL or XML (SAML). We check them immediately: an unreachable issuer or invalid metadata is rejected with an explanation, not discovered at the first sign-in.

4. Verify your email domain with a DNS TXT record, see Email domain verification.

5. Test the sign-in in a private browser window with an account of your identity provider.

The setup guide stays available on the configuration page after activation. The Service provider details panel always shows these values for your configuration.

All values contain the ID of your configuration (<id> below) and are shown ready to copy in the dashboard.

The sign-on URL starts a sign-in through your identity provider directly. Use it for app tiles in My Apps, the Okta dashboard or bookmarks.

Client type: confidential web application with a client secret, using the Authorization Code flow. Public clients, the Implicit flow, the Device Code flow and Resource Owner Password Credentials are not supported.

Issuer: the address under which your identity provider serves /.well-known/openid-configuration. We discover all endpoints from there and check the issuer when you save it.

Metadata: enter the metadata URL of your identity provider, or paste its metadata XML if it offers no URL. A metadata URL is reloaded every night, so certificate rollovers at your identity provider need no action; with pasted XML, paste the new metadata after a rollover. The dashboard shows the signing certificates and their expiry.

Bindings: we send the authentication request signed via HTTP-Redirect and receive the response via HTTP-POST. Responses or assertions must be signed; encrypted assertions are supported with the certificate from our service provider metadata.

Name ID: the Name ID identifies the user on every later sign-in. Prefer a persistent Name ID; an email-formatted Name ID works as well.

Attributes we read (names are matched case-insensitively):

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 identities for domains it has no authority over. The verification proves that you control the domain and therefore your identity provider may vouch for identities within it.

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 checks pending domains automatically every 10 minutes. You can also press Verify to check immediately.

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

When a member enters their work email on the sign-in page, TrustComponent finds the active SSO configuration for the email’s domain and sends the member to your identity provider. After the identity provider confirms the member, we map the sign-in to a TrustComponent user in one of three ways:

• Returning sign-in. A member who is already linked signs in immediately. The email domain is not checked again — the email at your identity provider may legitimately change later.
• Email match for an existing user. A TrustComponent user with the same verified email is linked automatically and signed in. The user receives an email about the new link, and the link appears in the audit log.
• First-time signup. Otherwise the member confirms their name and accepts our terms once. We send a verification email to the address; clicking it creates the account, linked to your identity provider and without a password.

Account switching. TrustComponent asks the identity provider to prompt for fresh credentials on every sign-in (prompt=login for OIDC, ForceAuthn for SAML), and passes the entered email along where the protocol allows it.

Signing out works in both directions, so that a second person on the same computer does not end up in the first person’s account, and signing out at your identity provider also ends the member’s TrustComponent sessions.

Identity providers without the respective support (e.g. Google) sign members out of TrustComponent only.

A TrustComponent user can authenticate by SSO, by local password, or by both.

SSO-only users. Users created through first-time signup have no local password and sign in through SSO.

Removing the SSO connection. A user can unlink SSO in their security settings, unless it is their only sign-in method.

Multi-factor authentication. TrustComponent’s own multi-factor authentication (TOTP and passkeys) is independent of the sign-in method. If a user has it enabled, it is always required — after SSO as well as after a password, regardless of whether your identity provider already enforced MFA.

A company with several projects — or with an agency and projects — needs only one SSO configuration. Share it with a join code instead of setting up your identity provider again:

1. In the project or agency that owns the configuration, open Governance › Single Sign-On, open the menu of the configuration and choose New join code. Give it a short description and set how many projects or agencies may use it.
2. Send the code to the admins of the others. It is valid for 7 days and works as often as you set. The full code is shown only once; afterwards the configuration lists it by its last four characters, with its uses and expiry, and you can revoke it there.
3. In the other project or agency, open Governance › Single Sign-On, choose Add Existing and enter the code.

The configuration then counts towards the single sign-on limit of each of them. Everyone who manages single sign-on in one of the linked projects or agencies can manage it, and provisioning rules stay separate per project or agency. Deleting the configuration removes it everywhere.

With provisioning rules, members who sign in through your identity provider join your project or agency automatically, and their roles follow the groups and attributes your identity provider sends. You no longer invite each colleague by hand, and people who leave a group lose the roles it gave them at their next sign-in.

You manage the rules under Team & Access › Single Sign-On Provisioning. A rule always belongs to one SSO configuration of your project or agency, so you create or link the configuration first. Whether provisioning is available depends on your plan and add-ons.

Each rule has a name, an SSO configuration, a list of conditions and the roles it grants — in an agency, the agency roles and the client project roles.

• Conditions compare a claim (OIDC) or an attribute (SAML) of the sign-in with a value, for example groups = trustcomponent-admins. A condition is met when the claim contains the value exactly — upper and lower case matter. A rule with several conditions only applies when all of them are met; a rule without conditions applies to everyone who signs in through the configuration. A rule can have up to 10 conditions.
• Several rules can apply to the same person; the member then receives the roles of all of them.
• The rules are checked at every sign-in. A member who no longer meets a rule loses the roles it granted. If no rule applies any more and the member was only added by provisioning, the membership ends.
• A paused rule grants nothing; the roles it granted are removed at the next sign-in.

A person who meets a rule and is not yet a member joins at the end of their sign-in — no invitation email, no extra step. The audit log records the invitation and its acceptance.

If no seat is left, the invitation stays open instead. The person sees it on their Home page, with the Accept button locked until a seat is free; you see it under Team & Access › Invitations. As soon as a seat is available, the person accepts the invitation there, or joins automatically at their next sign-in.

If your plan no longer includes provisioning, the rules are suspended. You can still pause or delete them.

Most identity providers only send group information once you configure it. Use the claim or attribute name you choose there as the claim name in your rule.

With OpenID Connect, add the scope your identity provider needs for the groups claim (often groups) to the Scopes of your configuration. Every other claim or attribute works as well — for example a department or a job title.

If an SSO configuration is removed from your project or agency, or deleted, all roles and memberships that came only from its rules end. Members who were also added by hand stay, with the roles assigned by hand.

On the configuration page, scroll to Delete Single Sign-On, type the configuration’s label to confirm, and delete. All connections between TrustComponent users and this configuration are detached; the user accounts themselves stay. Roles and memberships that came only from provisioning rules of this configuration end, and its rules are removed. Users with a local password keep signing in as usual; users who relied exclusively on SSO recover access with the password reset flow.

If the project or agency this configuration belongs to is deleted, the configuration enters a 7-day grace period. It still works during this period but can no longer be managed from the dashboard.

Members are not sent to the identity provider. The email domain is not verified yet, or the configuration has no identity provider connected. The configuration page shows the status — Identity provider missing or Domain verification pending. DNS changes can take a while; press Verify to check again.

The sign-in is rejected after the identity provider. The identity provider returned an email address whose domain is not verified on this configuration, or no email at all. Check the email claim or attribute, and that the user’s address belongs to a verified domain.

A provisioning rule does not apply. Compare the claim name and value exactly — upper and lower case matter. With Microsoft Entra ID, use the group’s object ID. With OpenID Connect, check that the scope for the groups claim is in the configuration’s Scopes.

A user signs in with the wrong account. We ask the identity provider for a fresh sign-in every time. If the identity provider still reuses a session, sign out there first.

SAML stopped working after a certificate change. With a metadata URL, the new certificate is picked up overnight. With pasted metadata XML, paste the new metadata.

The identity provider is gone and nobody can sign in. Users without a password use the password reset flow with their email address to set one — see User Profile.

For anything else — verifying a domain without DNS access, more domains per configuration, restoring a configuration scheduled for deletion, or an identity provider not covered above — reach out at mail@trustcomponent.com.