How Single Sign-On Works

In single sign-on your identity provider proves who the user is with a signed message, and TestInvite checks that message before letting the user in — no TestInvite password is involved.

Published 2026/10/19

This page explains single sign-on (SSO) for readers who are new to it. You do not need to know any of this to set SSO up, but it makes every setting and every error message easier to understand.

The idea in one paragraph

Think of a building with a reception desk. Instead of every office handing out its own keys, the reception checks your ID once and gives you a visitor badge that every office trusts. In SSO, your company's identity provider is the reception desk, TestInvite is one of the offices, and the badge is a short, digitally signed message that says “this is ayse.yilmaz@company.com, and I checked her password and second factor just now.” TestInvite never sees the password; it only checks that the badge is genuine, fresh and meant for TestInvite.

Words you will meet

Term	What it means	Everyday comparison
Identity provider (IdP)	The system that holds your company accounts and checks passwords: Microsoft Entra ID (Azure AD), ADFS, Okta, Google Workspace, Keycloak and others.	The reception desk that checks IDs
Service provider (SP)	The application people sign in to. Here: TestInvite.	An office in the building
SAML 2.0	An XML-based SSO standard, used by enterprises for 20 years.	One badge format
OpenID Connect (OIDC)	A newer SSO standard built on OAuth 2.0; messages are JSON tokens.	Another badge format
Assertion / ID token	The signed message that says who the user is (SAML calls it an assertion, OIDC an ID token).	The badge
Attribute / claim	A piece of information inside the assertion or token: email, first name, last name…	The name printed on the badge
Certificate	The public half of the key your IdP signs with. TestInvite uses it to check that a message really came from your IdP.	The reception's official stamp
Metadata	A file (usually at a URL) that lists an IdP's or SP's identifiers, addresses and certificates, so the other side can be set up in one step.	A business card
Entity ID	The unique name of an IdP or SP in SAML.	The name on the business card
ACS URL / Redirect URI	The TestInvite address the IdP sends the user back to after sign-in (SAML: ACS URL, OIDC: Redirect URI).	The office door the visitor is sent to

What happens when someone signs in

This is the normal flow, called SP-initiated because it starts at TestInvite:

The user opens your organization's TestInvite sign-in page and clicks Continue with SSO (or types an email on one of your SSO domains, which leads to the same button).
TestInvite creates a one-time sign-in request and sends the user's browser to your identity provider. (SAML: an AuthnRequest; OIDC: an authorization request with a random state, nonce and PKCE challenge.)
Your identity provider signs the user in the way it always does — password, Windows sign-in, multi-factor authentication, conditional access. TestInvite takes no part in this step.
Your identity provider sends the browser back to TestInvite with the signed answer (SAML: a signed response posted to the ACS URL; OIDC: a short-lived code that TestInvite's server exchanges for a signed ID token).
TestInvite checks the answer: the signature, who issued it, who it is for, that it is fresh, that it answers the request TestInvite sent, and that it has not been used before.
TestInvite reads the email (and name) from the answer and checks that the email is on one of your organization's SSO domains.
TestInvite finds the person: the organization owner, an existing user with that email, or — if automatic user creation is on — a new user.
The user lands in TestInvite, signed in.

The whole round trip normally takes one or two seconds. If any check fails, the user sees an error page with an error code; each code is explained in SSO Troubleshooting.

Starting from the identity provider (IdP-initiated)

Some companies give people an app portal — Microsoft My Apps, the Okta dashboard, the ADFS sign-on page — where they click a TestInvite tile. There are two ways to make such a tile work:

Recommended: point the tile at your organization's Sign-in URL (shown in the SSO settings). Clicking it starts the normal SP-initiated flow above, so every check stays in place.
IdP-initiated SAML: the identity provider sends a signed response without TestInvite having asked for it. TestInvite accepts this only when Allow sign-in from the identity provider portal is on. All other checks still apply, and each response can be used only once.

What keeps it secure

Signatures: every SAML response (or its assertion) and every OIDC ID token must be signed by your identity provider. TestInvite accepts only the certificates you configured (SAML) or the keys your identity provider publishes (OIDC).
Issuer and audience: the message must come from your identity provider and be addressed to TestInvite for your organization — a message made for another application is rejected.
Freshness: messages are valid only for the few minutes your identity provider allows; TestInvite tolerates up to 3 minutes of clock difference.
Request matching: a response must answer a sign-in request TestInvite started in the last 15 minutes (SAML InResponseTo; OIDC state, nonce and PKCE).
Single use: a SAML assertion is accepted once; the one-time link TestInvite uses to finish the sign-in is valid for 5 minutes and also works only once.
Domain restriction: only emails on the domains you list can sign in with SSO, so an identity provider cannot sign anyone in under an address your organization does not own.
Secrets stay on the server: the OIDC client secret and TestInvite's private keys are stored encrypted on TestInvite's servers and are never sent to a browser.
Optional extras: signed sign-in requests and mandatory encrypted assertions (SAML). See SSO Settings Reference.

How a person is matched to a TestInvite user

TestInvite identifies people by email. That is why unique emails must be turned on before SSO: one email must lead to exactly one person. The order is: the organization owner account with that email, then an existing user with that email (who is linked to SSO from then on, keeping their username), then — only if automatic user creation is on — a new user whose username is the email. Details: SSO Settings Reference → Automatic user creation.

Go back