SSO Settings Reference

Every SSO setting explained: what it is, what it enables, an example, and what happens when it is wrong — from the protocol and identity provider values to domains, enforcement, attribute mapping and automatic user creation.

Updated 2026/10/19

SSO is configured by the organization owner under Organization → Configure → Sign-in & Security → edit → Single Sign-On. The screen has five numbered sections, in the order you fill them in. This page describes every field. Changes take effect only when you click Save.

Before SSO can be turned on: unique emails must be enforced (same dialog, User Management), at least one email domain must be set, and Test SSO must have passed with the current connection settings.

Status

On / Off — whether SSO is active for your users right now (the saved state).
Connection tested — a passed Test SSO covers the settings on screen. Settings changed since the last passed test means you edited a connection setting; run Test SSO again before saving with SSO on. Not tested yet means no test has passed.

1. Protocol

SAML 2.0 or OpenID Connect. Decides which fields appear in sections 2 and 3. Both protocols' values are kept while you switch, but only the selected protocol is saved. Help choosing: SAML or OIDC.

2. Values for your identity provider

Read-only values that describe TestInvite to your identity provider. They are built from your organization ID and never change. Each has a copy button. Replace <ORG-ID> below with your organization ID (shown in the Organization page's info menu, next to the page title).

Value	Also called	Your value
Entity ID (SAML)	Identifier, Audience URI, Relying party identifier, SP Entity ID	`https://www.testinvite.com/api/v1/auth/sso/<ORG-ID>/saml/metadata`
ACS URL (SAML)	Reply URL, Assertion Consumer Service URL, Single sign-on URL, Recipient	`https://www.testinvite.com/api/v1/auth/sso/<ORG-ID>/saml/acs`
Metadata URL (SAML)	SP metadata, federation metadata	`https://www.testinvite.com/api/v1/auth/sso/<ORG-ID>/saml/metadata`
Redirect URI (OIDC)	Callback URL, Reply URL, Sign-in redirect URI	`https://www.testinvite.com/api/v1/auth/sso/<ORG-ID>/oidc/callback`
Sign-in URL (both)	Sign-on URL, Login URL, App launch URL	`https://www.testinvite.com/api/v1/auth/sso/<ORG-ID>/initiate`

The Entity ID is the metadata URL itself, so identity providers that monitor metadata can follow it.
The metadata contains the Entity ID, the ACS URL (HTTP-POST), TestInvite's encryption certificate and — when Sign authentication requests is on — its signing certificate. Download metadata saves the same file, for identity providers that cannot reach the URL.
The Sign-in URL starts an SSO sign-in directly. Use it for bookmarks, intranet links and identity provider app tiles. It accepts an optional returnTo parameter (a TestInvite path such as /app/...) to land on a specific page after sign-in.

3. Identity provider details — SAML

Field	What it is	Example	If it is wrong
Identity provider metadata URL	Where TestInvite reads your identity provider's values. Click Import to fill the fields below. Once saved, TestInvite re-reads it at most once a day (and immediately after a signature failure), so certificate renewals are picked up automatically.	ADFS: `https://adfs.company.com/FederationMetadata/2007-06/FederationMetadata.xml`; Entra ID: the App Federation Metadata Url	Import fails with a message. The URL must use https and be reachable from the internet; otherwise use Upload metadata XML.
Upload metadata XML	Reads the same values from a downloaded metadata file. No automatic refresh.	`FederationMetadata.xml`	Import fails with a message (not metadata, no identity provider, missing values).
Entity ID / Issuer	Your identity provider's unique name. Every response must carry exactly this issuer.	ADFS: `http://adfs.company.com/adfs/services/trust`; Entra ID: `https://sts.windows.net/<tenant-id>/`	Sign-in fails with `ISSUER_MISMATCH`.
SSO URL	Where TestInvite sends the sign-in request (HTTP-Redirect binding).	ADFS: `https://adfs.company.com/adfs/ls/`	The identity provider shows an error page or the browser cannot reach it.
Signing certificates	Public certificate(s) your identity provider signs with (PEM or Base64). Each shows its expiry date; certificates expiring within 30 days are highlighted.	`-----BEGIN CERTIFICATE----- MIIC8D…`	Sign-in fails with `SIGNATURE_INVALID`.

Certificate renewal without downtime: responses signed by any listed certificate are accepted. Add the new certificate before your identity provider switches to it, and remove the old one afterwards. With a metadata URL this happens automatically.

Security options (SAML)

Option	What it does	When to turn it on
Sign authentication requests	TestInvite signs every sign-in request with its own certificate (RSA-SHA256). The signing certificate is added to TestInvite's metadata.	When your identity provider requires signed requests (for example ADFS with SignedSamlRequestsRequired). Update TestInvite's metadata in your identity provider afterwards.
Require encrypted assertions	Responses whose assertion is not encrypted to TestInvite's certificate are rejected. Encrypted assertions are always accepted, even when this is off.	When your security policy requires encryption. Your identity provider needs TestInvite's metadata (it contains the encryption certificate).
Allow sign-in from the identity provider portal	Accepts responses that TestInvite did not request (IdP-initiated sign-in), for app tiles that post directly to the ACS URL. Every other check still applies, and each response can be used once. A deep link may be passed as RelayState (a TestInvite path).	Only when users must start from an identity provider portal and pointing the tile at the Sign-in URL is not possible.

3. Identity provider details — OIDC

Field	What it is	Example	If it is wrong
Issuer URL	Your identity provider's issuer. TestInvite reads `<issuer>/.well-known/openid-configuration` and requires its `issuer` to match.	Entra ID: `https://login.microsoftonline.com/<tenant-id>/v2.0`; ADFS: `https://adfs.company.com/adfs`; Okta: `https://company.okta.com`; Keycloak: `https://sso.company.com/realms/company`; Google: `https://accounts.google.com`	`DISCOVERY_FAILED`
Client ID	The application (client) ID your identity provider assigned.	`3f2b1c9e-…`	`TOKEN_EXCHANGE_FAILED` or `AUDIENCE_MISMATCH`
Client secret	The secret your identity provider generated. Stored encrypted and never shown again; leave empty to keep the stored secret. Changing it requires a new test.	—	`TOKEN_EXCHANGE_FAILED`
Client authentication	How the secret is sent to the token endpoint: Basic (HTTP Authorization header, `client_secret_basic`) or Post (form body, `client_secret_post`).	Basic (default)	`TOKEN_EXCHANGE_FAILED` (invalid_client)
Scopes	What TestInvite asks for. `openid` is always included.	`openid email profile`; ADFS: add `allatclaims`	`EMAIL_MISSING` when the email is not released

4. Users

Email domains

The email domains your identity provider is responsible for (press Enter after each). Example: company.com, company.com.tr.

An SSO sign-in is rejected (EMAIL_DOMAIN_NOT_ALLOWED) when the email is not on one of these domains.
Matching is exact and ignores letter case: company.com does not cover hr.company.com.
On the sign-in page, people who type an email on these domains are guided to SSO.
Under Required enforcement, users whose email is on these domains cannot use a password.

Enforcement

Mode	What users experience
Optional	SSO is offered next to password sign-in. Everyone can still use a password. Use this while rolling out.
Required	Users governed by SSO must sign in through your identity provider: password sign-in and password reset stop working for them, and self sign-up is turned off. A user is governed by SSO when they have signed in with SSO before, or their email is on one of your SSO domains. Other users (for example external candidates with a gmail.com address) keep their password.

The organization owner account always keeps password sign-in, even under Required. Keep its password safe: it is your way back in if your identity provider is unavailable or misconfigured.

Attribute mapping

Which attribute (SAML) or claim (OIDC) holds the email, first name, last name and display name. Leave a field empty for Automatic, which covers ADFS, Entra ID, Okta, Google Workspace and Keycloak defaults:

Value	Automatic detection (first match wins)
Email	`email`, `mail`, `emailaddress`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`, `urn:oid:0.9.2342.19200300.100.1.3`; then, if email-shaped: `upn`, `preferred_username`, `unique_name`; then an email-shaped SAML NameID
First name	`given_name`, `givenName`, `firstName`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`, `urn:oid:2.5.4.42`
Last name	`family_name`, `surname`, `sn`, `lastName`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`, `urn:oid:2.5.4.4`
Display name	`name`, `displayName`, `http://schemas.microsoft.com/identity/claims/displayname`, `cn` (ignored when it is an email address)

The user's name is the display name, or first name + last name when there is no display name.
Set a field only when your identity provider uses another name. The Test SSO report lists every attribute received, with a copy button.
Emails are compared in lower case.

Automatic user creation (just-in-time provisioning)

After a successful SSO sign-in, TestInvite looks for the person by email, in this order:

The organization owner account with that email → signs in as the owner.
An existing user with that email → signs in as that user. From then on the user is marked as managed by SSO; the username does not change; the name is updated from the identity provider on every SSO sign-in.
No one found → with automatic user creation on, a new user is created: username = email, name from the identity provider, and the user type (learner, or teammate with the selected roles), folder and group you choose. With it off, the sign-in is refused (USER_NOT_FOUND), so only people you created beforehand can sign in.

Deactivated users (USER_INACTIVE) and users outside their access dates (USER_ACCESS_DENIED) are refused in every case. Users managed by SSO are marked in the user list; their username, email and password are read-only in TestInvite, because the identity provider owns them.

5. Test SSO

Runs a real sign-in with the settings on screen without saving them and without signing anyone in. See Testing Your SSO Connection.

Turn on single sign-on, and Save

The switch at the bottom turns SSO on or off for your users; Save applies everything. Saving with SSO on is refused, with a message, when unique emails are not enforced, no domain is set, a domain or certificate is invalid, identity provider values or the client secret are missing, or no passed test covers the current connection settings.

Connection settings — the ones that require a new test when changed — are: the protocol, all identity provider values (including the metadata URL, certificates, client ID and secret, client authentication and scopes), the SAML security options, the email domains and the attribute mapping. Enforcement and automatic user creation can be changed at any time without a new test.

Go back