Choosing SAML 2.0 or OpenID Connect

SAML and OIDC give users the same sign-in and the same security in TestInvite; the practical difference is that OIDC needs your identity provider's token endpoint to be reachable from the internet, while SAML does not.

Published 2026/10/19

TestInvite supports both SSO standards with the same features: email domains, enforcement, attribute mapping, automatic user creation and Test SSO. Your users will not notice which one you chose. Pick the one your identity provider team is most comfortable with.

	SAML 2.0	OpenID Connect (OIDC)
Typical users	Enterprises, ADFS, Entra ID, Okta, Google Workspace, Keycloak, banks and public institutions	Modern cloud identity providers; teams that already use OAuth 2.0
What you set up in the identity provider	An application (relying party) with TestInvite's Entity ID and ACS URL — or simply TestInvite's metadata URL	A web application (confidential client) with TestInvite's Redirect URI
What the identity provider gives you	Its metadata URL or file (Entity ID, SSO URL, signing certificate)	Issuer URL, client ID and client secret
Who talks to whom	Only the user's browser talks to your identity provider	The browser, and TestInvite's servers (to exchange the code for tokens and to read the signing keys)
Network requirement	Your identity provider can stay on the internal network or VPN, as long as users' browsers reach it	Your identity provider's token endpoint and keys (JWKS) must be reachable from the internet
Secrets to manage	None (only public certificates)	A client secret, which usually expires and must be renewed
Certificate / key renewal	Automatic when you use the metadata URL; otherwise add the new certificate before the switch	Automatic (keys are read from the identity provider)
Optional extras	Signed requests, mandatory encryption, sign-in from the identity provider portal	—

Choose SAML if…

your identity provider is not reachable from the internet (common with ADFS behind a VPN);
you do not want to manage a client secret that expires;
your security team requires encrypted assertions or signed requests;
your users start applications from an identity provider portal (Microsoft My Apps, Okta dashboard).

Choose OIDC if…

your identity provider team recommends it (for example, ADFS teams often prefer OAuth/OIDC for new applications);
your identity provider is a cloud service (Entra ID, Okta, Google) and the token endpoint is public anyway;
you prefer JSON tokens and a single client ID / secret pair over certificates.

You can switch protocols later. Users, domains, enforcement and automatic user creation stay as they are; you only enter the new identity provider values and run Test SSO again.

Requirements in detail

SAML 2.0

Sign-in requests: HTTP-Redirect binding. Responses: HTTP-POST binding to the ACS URL.
The response or the assertion must be signed (RSA with SHA-256 recommended). Unsigned responses are always rejected.
Any NameID format is accepted; TestInvite does not request a specific one. The email is read from the attributes or, if none is found, from an email-shaped NameID.
Encrypted assertions are accepted (TestInvite's encryption certificate is in its metadata).
TestInvite does not request a specific authentication method, so Windows integrated sign-in, passwords and MFA all work.
Single logout (SLO) is not used: signing out of TestInvite does not sign the user out of the identity provider.

OpenID Connect

Authorization Code flow with PKCE (S256), state and nonce.
Discovery document at <issuer>/.well-known/openid-configuration over https, whose issuer matches the issuer you enter.
Client authentication with client_secret_basic (default) or client_secret_post.
A signed ID token (keys published at the JWKS URL). The email is read from the ID token, or from the userinfo endpoint when the ID token has none.

Go back