SaaS SSO setup: SAML and OpenID Connect integration checklist
Plan enterprise single sign-on with SAML or OpenID Connect, verified tenant mapping, safe account linking, tested certificates and a recovery path.
In this guide
What is single sign-on for SaaS?
Single sign-on (SSO) lets an organisation use an identity provider (IdP) to authenticate people into a SaaS service. SAML 2.0 and OpenID Connect (OIDC) are common federation choices: OIDC adds an identity layer on OAuth 2.0, while SAML conveys signed assertions in an XML-based protocol. SSO verifies an identity claim; your product still decides which tenant, role and resource access that identity receives.
Choose the protocol that fits the customer's identity provider
Ask which protocol the customer's IdP supports and what the integration must cover. OIDC commonly uses a redirect flow with an ID token; SAML commonly sends a signed assertion to an assertion consumer endpoint. Treat protocol differences as implementation choices and follow the relevant specification and vetted library rather than writing cryptography or XML signature handling yourself.
Keep authentication separate from authorization
Map the verified external identity to an account and tenant, then apply your existing authorization policy. An IdP group or claim should not become a privileged product role unless the tenant administrator configured and approved that mapping. SSO does not replace server-side role checks or tenant isolation.
Define identifiers that survive name and email changes
Prefer a stable issuer-plus-subject identifier for OIDC or a configured persistent identifier for SAML. Email addresses can change, be reassigned or be unverified; do not automatically merge an SSO identity with an existing password account solely because the email strings match. Design account linking as an explicit, verified operation.
| Tenant / IdP | Protocol and issuer | Redirect or ACS endpoint | Identity and role mapping | Certificate / recovery owner |
|---|---|---|---|---|
How do you configure SAML or OIDC safely?
Register exact redirect and assertion endpoints
For OIDC, validate the configured issuer, client, redirect URI, state and nonce according to the flow and library. For SAML, configure the entity identifiers, assertion consumer service URL, audience and expected signing keys. Reject unexpected destinations or issuers; do not accept a broad wildcard callback to make setup easier.
Validate signatures, audience, issuer and time bounds
Accept only assertions or tokens issued by the tenant's configured IdP, intended for your service and within acceptable validity windows. Use trusted metadata or configuration to manage keys, check signatures with vetted libraries and fail closed on malformed or unsigned responses. Never treat a decoded token as trusted before cryptographic and claim validation.
Bind each IdP configuration to one verified customer tenant
Require an authorised tenant administrator to complete setup and prove control of the organisation's domain or IdP configuration. Do not route a sign-in to a tenant based on an unverified email suffix alone. Keep issuer, tenant ID, signing key and allowed identity domains in a reviewable configuration record.
How should teams launch and support SSO?
Test failures and key rotation before enabling enforcement
Test wrong issuer, expired assertion, changed certificate, replayed response, clock skew, duplicate email and IdP outage. Give the customer a safe test mode and a clear configuration error. Rehearse signing-key rotation with overlapping trusted keys when the protocol and IdP support it, then remove obsolete keys after verification.
Plan break-glass recovery without creating a hidden bypass
If SSO is unavailable or misconfigured, define who can restore tenant access and how their identity is verified. Prefer a tightly controlled, audited recovery account or administrator-approved temporary route. Do not leave an undocumented shared password or permanent bypass that defeats the organisation's SSO policy.
Explain sign-out and session behaviour
A user signing out of your product may remain signed in at the IdP, and an IdP logout may not automatically revoke every product session. Document the supported behaviour, session lifetime and administrator controls. Revoke the product's own session and refresh credentials when membership is removed or an incident requires containment.
SaaS SSO questions
Should a new SaaS product choose SAML or OIDC?
Ask the target customers and identity providers. OIDC is a modern OAuth-based identity protocol; SAML remains common in enterprise SSO. Prefer a maintained, security-reviewed implementation and build only the protocol features your customers need.
Does SSO automatically create and remove user accounts?
Not necessarily. SSO authenticates a sign-in; account lifecycle provisioning is a separate process, often handled with SCIM or an administrator workflow. Define who may join and how access ends when a person leaves the organisation.
Is matching an SSO email to an existing account safe?
Not by itself. Email can change or be reassigned. Validate the IdP issuer and stable subject, then require a deliberate, verified account-linking process before combining identities or privileges.
Can SSO assign an administrator role?
It can carry a group or attribute claim, but the product should map that value through a customer-approved policy and verify tenant scope. Authentication claims must not silently grant a privileged application role.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OpenID Connect Core 1.0, specification version 36OpenID Foundation
- Security Assertion Markup Language (SAML) v2.0OASIS Open
- IETF RFC 7644: SCIM ProtocolInternet Engineering Task Force
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- AWS SaaS Lens: Preventing cross-tenant accessAmazon Web Services