SaaS SSO Requirements Checklist: Scope Enterprise Identity Safely

Define what SSO will and will not own

Federation authenticates a person using a separate identity provider. It does not automatically create a correct product account, choose a SaaS tenant, grant permissions, synchronize a directory, or remove an active product session when employment ends. Keep these concerns explicit so a successful protocol test is not mistaken for a safe product release.

This separation also prevents overlap with your broader SaaS permissions requirements. SSO can carry a group or role claim, but the product still needs a tenant-safe rule for interpreting it and a fallback when it is missing, renamed, or unexpectedly broad.

Write an identity control contract across six surfaces

1. Tenant: connection ownership, verified domains, discovery rules, multiple domains, and what happens when a person belongs to more than one tenant.
2. Trust: protocol, issuer, entity or client identifier, endpoints, signing keys or certificates, metadata refresh, rotation, and allowed clock difference.
3. Account: stable identifier, email changes, account linking, duplicate handling, just-in-time creation, and whether personal login may coexist.
4. Session: session duration, IdP and product logout, reauthentication for costly actions, MFA expectations, and behavior after a policy change.
5. Authorization: default access, claim or group mapping, tenant-admin control, least-privilege fallback, and permission-change timing.
6. Operations: connection setup, test mode, audit events, health signals, certificate expiry, support access, incident response, and decommissioning.

Choose OIDC, SAML, and SCIM from customer evidence

Microsoft's current SSO planning guidance for software vendors recommends OIDC as the default for most modern SaaS products and retaining SAML for customer or legacy requirements. That is a useful starting point, not a substitute for checking the target customer's IdP, procurement requirement, and integration profile.

OIDC is an identity layer over OAuth 2.0. The OpenID Connect Core specification defines how a client verifies an authenticated user and receives claims. SAML uses signed XML assertions and remains common in enterprise identity systems. In either case, use a maintained, conformant library or managed identity platform; protocol parsing and token validation are poor places for bespoke shortcuts.

SCIM is separate. RFC 7644 defines a protocol for managing identities such as users and groups. Add it when automated onboarding, attribute updates, suspension, or group synchronization is part of the customer requirement. Do not claim “automatic offboarding” if the product only blocks the next federated sign-in while existing sessions or manually created accounts remain active.

Design the lifecycle, failure path, and recovery path

Specify the first visit before the happy-path return visit. Will users enter an email, use a tenant-specific URL, begin from an IdP tile, or choose among connections? Define how a verified domain maps to a tenant and what the product does when no match, multiple matches, an unverified domain, or an existing personal account is found. Never rely on an email domain alone as proof of tenant membership.

Then test change and failure: an email is renamed, a group is removed, a certificate expires, a signing key rotates, the IdP is unavailable, the assertion is replayed, the account is suspended, or an administrator misconfigures a claim. NIST's federation and assertions guidance treats the relationship among identity provider, relying party, assertions, and disclosed attributes as a trust system. Record only the attributes the product needs and define their allowed use.

Recovery must not become a shadow login. The OWASP Authentication Cheat Sheet recommends reauthentication after high-risk events and separates authentication from session management. Decide who can disable a connection, how tenant admins regain control, what support can see, which actions require dual approval, and how active sessions are revoked.

Require evidence for normal, negative, and operational cases

Acceptance should show more than one successful login. Use a customer-like test tenant and capture the input, expected result, visible result, audit event, and owner for each scenario.

• SP-initiated and IdP-initiated paths where each is promised, including deep links and the post-login destination.
• Correct tenant routing for known, unknown, ambiguous, and disabled connections without exposing tenant information.
• Account creation and linking with immutable identifiers, changed email addresses, duplicates, and an already authenticated user.
• Invalid issuer, audience, signature, redirect, state, nonce, expired assertion, clock difference, and replay attempts.
• Role or group changes, removal from the directory, suspension, session revocation, and the promised propagation delay.
• Key or certificate rotation, connection health, administrator notification, support diagnosis, and a rehearsed rollback.

Authentication, permission changes, connection administration, recovery, and failures should produce reviewable events. Use the SaaS audit log requirements checklist to define actor, tenant, action, target, time, outcome, and relevant context without logging tokens or sensitive assertion contents.

Use a one-connection requirements brief

Complete the brief with customer IT, the SaaS product owner, a security reviewer, support, and engineering. Attach example metadata or discovery documents, attribute names, tenant rules, session policy, lifecycle expectations, negative tests, recovery owners, and launch evidence. Mark unknowns instead of turning assumptions into requirements.

If the account, tenant, or authorization model cannot support the connection safely, scope that foundation before adding more connectors. Leeonex's MVP and SaaS development service can help shape an incremental product boundary, while the web application security requirements guide covers the wider authentication, authorization, data, and operational controls around the feature.

Frequently asked questions