Most single sign-on weaknesses are not in the identity provider but in the individual application connection: a service provider that accepts unsigned assertions, an OIDC client that never checks the nonce, a redirect URI with a wildcard or a local password login left open beside SSO. This template is a go-live sign-off for one application integration, covering both SAML 2.0 and OpenID Connect. Each check has a requirement level and a way to verify it against the running connection, drawn from the OWASP Application Security Verification Standard 5.0, the OWASP SAML Security Cheat Sheet, OpenID Connect Core 1.0 and RFC 9700, the OAuth 2.0 security best current practice. It is written for identity engineers, application owners and security reviewers who approve new SSO connections. Replace the values in square brackets and use it as part of your change process.
How to use this template
- Complete one copy per application and per environment. A test tenant connection signed off on its own does not prove the production connection is the same.
- "Must" items block go-live. "Should" items need a recorded exception under section 9 with an owner and an expiry date.
- Complete section 5 for SAML or section 6 for OIDC, not both, unless the application supports both and both are enabled. Sections 4, 7 and 8 apply to every integration.
- Mark a check as met only when the "Verify" test has been run against the live connection, ideally by someone other than the person who configured it. A screenshot of a configuration screen is weaker evidence than a negative test that was rejected.
- For the protocol background, read the SAML Security Guide, the SAML vs OIDC Guide and the Identity Provider and SSO Security Guide. This checklist does not repeat them.
1. Purpose
This checklist sets the minimum configuration that a SAML or OpenID Connect integration between [Organisation]'s identity provider and an application must meet before users rely on it, and the evidence that proves it. It exists because the identity provider can only issue a well-formed assertion or token: whether that assertion is validated, scoped and bound to the right session is decided by the application, often by a library default or a vendor setting nobody reviewed.
2. Scope
- Every new SSO connection for workforce applications, whether software as a service, self-hosted or built in house, where [Organisation]'s identity provider is the SAML identity provider or the OpenID provider.
- Material changes to an existing connection: new signing certificate, new redirect URI or assertion consumer service URL, new claims or attributes used for authorisation, protocol change (see the SAML to OIDC Migration guide).
- Customer-facing applications that use [Organisation]'s customer identity platform, with the customer-specific items marked in section 6.
- Out of scope: machine-to-machine OAuth clients with no user (use the OAuth Client Registration Checklist) and workload federation (use the Workload Identity Federation Trust Review Checklist).
3. Roles and responsibilities
| Role | Responsibility in this checklist |
|---|---|
| [Application owner] | Names the business purpose, user population and data classification; owns the application-side settings and local accounts. |
| [Identity engineering] | Configures the identity provider side: application registration, claims, assignment, conditional access, certificates. |
| [Application security reviewer] | Runs the negative tests in sections 5 and 6 and signs the checklist; must not be the person who configured the connection. |
| [Security operations] | Confirms the sign-in and audit logs in section 8 arrive in [SIEM] before go-live. |
4. Common checks for every integration
| # | Requirement | Level | Verify |
|---|---|---|---|
| 4.1 | The application is recorded in [Application inventory] with owner, data classification and the protocol used. | Must | Inventory record linked to this checklist. |
| 4.2 | Access is limited to assigned users or groups at the identity provider; "all users can sign in" is not enabled unless the owner has approved it. | Must | Sign in as an unassigned test user: access is refused at the identity provider. |
| 4.3 | The integration requires the authentication strength set for the data classification (for example phishing-resistant MFA for [Confidential] data), enforced at the identity provider and, where the application needs it, checked by the application (see 6.9). | Must | Sign in with a password-only or weaker-factor test user: refused or stepped up. |
| 4.4 | Local username and password login is disabled for SSO users, or limited to named break-glass accounts that are vaulted, have MFA and are monitored. ASVS 5.0 V6.1.3 requires every authentication pathway to be documented with consistent strength. | Must | Attempt local login with an SSO user's email address: refused. Break-glass list attached. |
| 4.5 | The user identifier the application stores is immutable and not reassignable: a persistent NameID or the OIDC sub, not an email address that can change or be reissued (ASVS 5.0 V10.5.2). | Must | Account linking code or vendor setting reviewed; rename test user's email and confirm the same account is used. |
| 4.6 | Only the attributes or claims the application needs are released. Group or role claims used for authorisation are filtered to the groups relevant to this application. | Must | Decoded assertion or ID token attached, with each attribute justified. |
| 4.7 | Provisioning and deprovisioning are defined: SCIM or another automated method, or a documented manual process. Disabling a user at the identity provider removes access within [24 hours], including any long-lived application session or API token the user created. | Must | Disable a test user and record how long access remained. |
| 4.8 | Session lifetime in the application is set and does not exceed [12 hours] for [Confidential] data; logout behaviour is documented (see the OpenID Connect Logout and Session Management Guide). | Should | Session cookie expiry observed; logout tested. |
| 4.9 | All endpoints (assertion consumer service, redirect URIs, metadata, JWKS) use HTTPS only. | Must | Configuration export shows no http:// URLs except native app loopback. |
| 4.10 | Application administrator roles are granted through groups from the identity provider, not set by hand in the application, and the admin group has a named owner. | Should | Admin role mapping recorded. |
5. SAML 2.0 service provider checks
These are checks on the service provider, which is where assertion validation happens. They follow the OWASP SAML Security Cheat Sheet and ASVS 5.0 V6.8.
| # | Requirement | Level | Verify |
|---|---|---|---|
| 5.1 | Signatures on the assertion (or on the response covering the assertion) are always validated; unsigned assertions and invalid signatures are rejected (ASVS 5.0 V6.8.2). | Must | Replay a captured response with the signature removed and with one attribute edited: both rejected. |
| 5.2 | The service provider validates against the identity provider's key from trusted metadata or a pinned certificate, and ignores any KeyInfo certificate embedded in the message. | Must | Send a response signed with a self-generated key that includes its own certificate in KeyInfo: rejected. |
| 5.3 | The signed element is the element the application consumes (defence against XML signature wrapping): the signature reference resolves to the assertion actually read. | Must | Library and version recorded; vendor statement or wrapping test result attached. |
| 5.4 | Signature algorithm is RSA-SHA256 or stronger; SHA-1 signature and digest methods are rejected. | Must | Metadata and a decoded response show SHA-256. |
| 5.5 | Audience equals this service provider's entity ID; Destination and Recipient equal the assertion consumer service URL. | Must | Send an assertion issued for another service provider in the same tenant: rejected. |
| 5.6 | NotBefore and NotOnOrAfter are enforced with a small clock skew of [3 minutes] or less, and the server clock is synchronised. | Must | Replay an expired response: rejected. |
| 5.7 | Assertions are accepted only once within their validity period (ASVS 5.0 V6.8.3); InResponseTo matches an outstanding request for service provider initiated flows. | Must | Post the same valid response twice: second attempt rejected. |
| 5.8 | Identity provider initiated (unsolicited) SSO is disabled unless the business needs it; if enabled, RelayState is checked against an allowlist. | Should | Configuration recorded; RelayState pointing to an external URL is not followed. |
| 5.9 | Signing certificate expiry is recorded in [Certificate inventory], with a rotation owner. Where the application supports a metadata URL, it is used so rotation is automatic. | Must | Expiry date and owner in the inventory. |
| 5.10 | Assertion encryption is enabled where the application supports it and attributes include personal or sensitive data. | Should | Decoded response shows EncryptedAssertion. |
Signing key protection on the identity provider side, which is what makes forged SAML responses possible, is covered in the Golden SAML and Federation Trust Abuse Defence Guide.
6. OpenID Connect relying party checks
These follow OpenID Connect Core 1.0 section 3.1.3.7 (ID Token validation), RFC 9700 and ASVS 5.0 chapter V10.
| # | Requirement | Level | Verify |
|---|---|---|---|
| 6.1 | The authorisation code flow is used. The implicit flow (response_type=token or id_token token) and the resource owner password credentials grant are disabled for this client (RFC 9700; ASVS 5.0 V10.4.4). | Must | Client registration export shows allowed grant and response types. |
| 6.2 | PKCE with S256 is used by the client and enforced by the authorisation server; public clients cannot complete a flow without it. | Must | Attempt a token request without code_verifier: rejected. |
| 6.3 | Redirect URIs are registered in full and compared by exact string; no wildcards, no open redirectors on the redirect endpoint (ASVS 5.0 V10.4.1). | Must | Request with a modified redirect URI (extra path, subdomain, query): rejected by the identity provider. |
| 6.4 | The ID token is validated: signature with keys from the issuer's JWKS, iss exactly matching the issuer, aud containing this client_id, exp not passed, and the expected alg only (no none). | Must | Present an ID token issued to another client in the tenant: rejected. Present an expired token: rejected. |
| 6.5 | A nonce is sent and checked against the ID token, and state is bound to the user agent session (ASVS 5.0 V10.1.2, V10.5.1). | Must | Replay a callback from another browser session: rejected. |
| 6.6 | If the client talks to more than one authorisation server, it defends against mix-up attacks using the iss response parameter (RFC 9207) or distinct redirect URIs (ASVS 5.0 V10.2.2). | Must (if multiple) | Configuration recorded. |
| 6.7 | Confidential clients authenticate to the token endpoint with private_key_jwt or mutual TLS where supported; if a client secret is used, it is stored in [Secrets manager], has an expiry and an owner. | Must | Client authentication method recorded; secret location and expiry recorded. |
| 6.8 | Requested scopes are the minimum needed (ASVS 5.0 V10.2.3); offline_access is requested only if refresh tokens are genuinely needed. | Must | Authorisation request captured and scopes justified. |
| 6.9 | Where a function needs a given authentication strength or recency, the application checks acr, amr or auth_time from the token rather than assuming the identity provider enforced it (ASVS 5.0 V6.8.4, V10.3.4). | Should | Code or vendor setting reviewed. |
| 6.10 | Tokens stay where they are needed: in browser applications, access and refresh tokens are held by the backend (backend for frontend), not in browser storage (ASVS 5.0 V10.1.1). | Should | Browser storage inspected after sign-in. |
| 6.11 | Refresh tokens have an absolute lifetime of [30 days] or less and rotate on use, or are sender-constrained for public clients (RFC 9700; ASVS 5.0 V10.4.8). | Must (if issued) | Token policy recorded. |
| 6.12 | Customer-facing only: user consent is shown for third-party clients, and users can review and revoke consents (ASVS 5.0 V10.7.1 to V10.7.3). | Must (customer) | Consent screen and revocation tested. |
Scope design is covered in more depth in the SaaS Application Security Review Checklist.
7. Threat and framework mapping
| Threat | Checks | Framework reference |
|---|---|---|
| Forged SAML responses (MITRE ATT&CK T1606.002 SAML Tokens) | 5.1 to 5.4, 5.9 | NIST SP 800-53 IA-2, SC-23 |
| Token theft and replay (T1528 Steal Application Access Token, T1550.001 Application Access Token) | 5.6, 5.7, 6.2, 6.5, 6.10, 6.11 | NIST SP 800-53 SC-23, IA-5 |
| Bypass through a second login path | 4.4 | NIST SP 800-53 IA-2, AC-2; ASVS 5.0 V6.1.3 |
| Access left after leaving (T1078.004 Cloud Accounts) | 4.2, 4.7 | NIST SP 800-53 AC-2; NIST CSF 2.0 PR.AA-01, PR.AA-05 |
| Over-broad data release or authorisation | 4.6, 6.8 | NIST SP 800-53 AC-6; NIST CSF 2.0 PR.AA-05 |
| Weak authentication accepted | 4.3, 6.9 | NIST SP 800-53 IA-2, IA-8; NIST CSF 2.0 PR.AA-03 |
8. Logging and go-live evidence
- Identity provider logs: sign-in events for this application, including failures and conditional access results, reach [SIEM]. Confirm a test sign-in appears before go-live.
- Application logs: the application logs SSO successes and failures with the reason for rejection (bad signature, audience mismatch, expired assertion, nonce mismatch), plus admin role changes and local login attempts (NIST SP 800-53 AU-2).
- Configuration changes: changes to the application registration, signing certificates, redirect URIs, client secrets and claim rules at the identity provider raise an alert to [Identity engineering].
- Evidence pack: this completed checklist, the configuration exports, the negative test results and the decoded sample assertion or ID token (with personal data removed), stored in [Evidence repository].
9. Exceptions
An unmet "Should" item, or a "Must" item the application cannot technically meet (for example a vendor product that offers only identity provider initiated SAML), needs an exception recorded in [Risk register] with the reason, the compensating control, an owner and a review date no later than [6 months]. A missing "Must" item without an approved exception blocks go-live. Ask the vendor for the setting in writing and record the answer: features change, so confirm current behaviour in the vendor's documentation at each review.
10. Review
Re-run sections 4 to 6 when the connection changes materially (section 2), when the identity provider or the application vendor announces a change to its SSO implementation, and at least every [12 months] for applications holding [Confidential] data. Related documents: [Identity and Access Management Policy], [Authentication Standard], [Application Onboarding Procedure], [Incident Response Plan].
Implementation guidance
- Build a reusable test kit first: a test user with no assignment, a test user with weaker factors, a captured valid response or token, and a way to replay and edit it in a non-production tenant. Most negative tests in sections 5 and 6 then take minutes per application.
- Run the checklist on the test connection, then repeat the identity provider side checks (4.2, 4.3, 6.3, 6.7) on production, because registrations are often recreated by hand.
- Close local login last but before go-live: confirm break-glass accounts work, then disable password login for everyone else. Rollback is re-enabling local login for a named group while the SSO fault is fixed, recorded as an exception.
- Retro-fit existing applications by risk: start with applications holding [Confidential] data and those with admin access to other systems. Record results in the same format so the review cycle in section 10 has a baseline.
- Feed results back to procurement: unmet checks for software as a service products become questions in the SaaS Application Security Review Checklist and the Workforce SSO and Access Management RFP Template.
Small organisations with a handful of applications can run this checklist as part of each purchase. Larger estates should track the percentage of SSO applications with a signed checklist, the number with local login still enabled, the number of open exceptions past their review date, and the number of signing certificates or client secrets expiring within 30 days without a rotation ticket.
Standards and references
- OWASP: Application Security Verification Standard 5.0
- OWASP: SAML Security Cheat Sheet
- OpenID Foundation: OpenID Connect Core 1.0
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- MITRE ATT&CK: Forge Web Credentials: SAML Tokens
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · SAML Security Guide · SAML vs OIDC Guide · OAuth Client Registration Checklist