NIST's federation guidance treats an assertion as a verifiable statement from an identity provider to a relying party, which validates it before creating a session. Enterprise applications also have to decide which local account that statement represents and what that account may do. Provisioning introduces a separate path for creating, updating and disabling access. A test limited to whether single sign-on works cannot establish that the full identity lifecycle is secure.
Quick answer. A SAML, OIDC and SCIM penetration test should cover assertion or token validation, account linking, application role enforcement, SCIM client authorization, and the effect of provisioning and deprovisioning on existing access. Give the testers controlled identities and roles at the identity provider and application, then require evidence at each boundary. Stingrai's application testing covers authenticated roles, object and function authorization, and the APIs behind the application.
This guide is for security leads and procurement teams buying an assessment of an enterprise app, customer-facing SaaS product, or internal platform that supports workforce identity. It is not a configuration checklist for one identity provider. The buyer should identify each trust relationship and expected account behavior before selecting test cases.
Draw the identity boundary before testing
List the identity providers, SAML service providers, OIDC relying parties, SCIM clients and SCIM service providers involved. A single business workflow may cross more than one of these roles. Record which organization operates each component, which party holds signing keys or client credentials, which application maps external identities to local accounts, and which system decides roles. A third-party identity provider may be outside the buyer's testing authorization; the application response to its assertions may still be in scope.
Define the user states that matter to the business: a new hire, an existing account, a user with access to two organizations, a role change, a suspension, and a terminated account. Include any break-glass or local-login path. State the expected behavior for each state. If the product allows a user to keep a local session after an identity-provider change, decide whether and for how long that behavior is permitted before testing. The vendor cannot label a lingering session a defect without the buyer's policy.
Use controlled identities and synthetic data. Give the testers a standard user, a privileged user, and accounts whose identifiers or email addresses are similar enough to exercise account linking safely. For a multi-tenant product, use identities in distinct customer tenants. Preserve the mapping between the external federated identifier and the local account. This is essential evidence when the issue is not the login itself but the wrong account receiving the session.
Figure 1: Federated login, local authorization and provisioning are separate test lanes. Sources: OASIS SAML Core, OpenID Connect Core, RFC 7644 and NIST SP 800-63C.
Test SAML and OIDC as distinct federation paths
For SAML, the assessment should verify the application's handling of the issuer, signature, audience, subject, timing and destination conditions that its deployment relies on. OASIS SAML Core defines an AudienceRestriction element that addresses an assertion to specified audiences. The buyer should identify the expected service-provider identifier and assertion consumer endpoint so that the vendor can evaluate whether the application accepts only assertions intended for it. Capture the actual deployment profile and configuration; the existence of a SAML setting on a product page is not enough.
For OIDC, ask the tester to examine ID token validation, issuer configuration, audience, signing keys, nonce or transaction binding where the selected flow uses it, and the creation of the local application session. OpenID Connect Core with errata set 2 requires exact issuer matching and audience validation against the registered client ID. It also says the guaranteed unique end-user identifier is the combination of issuer and subject. A test should therefore verify that an email address or display name does not silently become the sole key for binding an external user to a local account unless the application's explicit linking policy safely permits it.
Where the application uses redirect-based OAuth flows, include registered redirect handling and the transaction link between the browser and the code exchange. RFC 9700 requires authorization servers to use exact string matching for registered redirect URIs, except for the specified localhost native-app port case. The vendor should test the actual client and authorization server under the agreed rules of engagement, not assume every OIDC deployment uses the same flow.
Test both expected success and expected rejection. A valid assertion for the right relying party should create the right local session. An assertion for another audience, an untrusted issuer, or a subject that cannot be safely linked should not grant access. The scope should ask for results at the application boundary, with tokens and assertions redacted in the shared report. NIST SP 800-63C calls for signature, audience and replay protection at its baseline federation assurance level; those categories are useful evidence headings even when the buyer is not claiming a NIST assurance level.
Verify what happens after login
An accepted assertion should identify the user; it should not by itself authorize every application function. The test must follow the identity into tenant membership, local role mapping, privileged workflows and object access. A standard user may authenticate perfectly and still reach an administrator function because the application trusts an unreviewed attribute or fails a local check. OWASP API5:2023 frames this as function-level authorization. OWASP API1:2023 addresses access to a specific object.
The buyer should write down which attributes the identity provider asserts, which group or role mappings the application uses, and whether a local administrator can override them. Test changes in those attributes and mappings with controlled accounts. Where several IdPs can serve the same application, ask how the product separates users with identical email addresses but distinct issuers. Where just-in-time provisioning is enabled, ask whether first login creates the intended account and role rather than inheriting an existing account through an ambiguous identifier.
Support access and delegated administration need separate attention. A help desk user may have a legitimate account recovery function without having unrestricted access to customer data. The report should show the role-to-function policy and the observed result. This makes the assessment relevant to access reviews and enterprise customer due diligence, rather than only to protocol conformance.
Test SCIM as a lifecycle and authorization API
SCIM is a provisioning protocol, not a login method. RFC 7644 requires a SCIM service provider to map the authenticated client to an access control policy for retrieving and updating SCIM resources. The scope should identify each provisioning client, the tenant or organizational data it is allowed to manage, and the attributes and group memberships it can change. A working bearer credential alone is not proof that the caller is authorized for every User or Group resource.
Ask the vendor to trace a controlled lifecycle: create the account, update selected attributes, change a group, disable or remove access according to the product policy, and examine the effect on current sessions and API tokens. The exact mechanism may be PATCH, PUT, DELETE or an active state change depending on the deployment. The test should report what the product actually supports and what its policy says should happen. Avoid turning a product-specific deprovisioning design into a universal SCIM rule.
Pay particular attention to the join between provisioning and federation. NIST SP 800-63C discusses binding pre-provisioned accounts to federated identifiers and keeping provisioned accounts synchronized. A user provisioned under one identity should not gain another user's account through a later federated login. A removed user's privileges should not quietly persist in a different local role or tenant membership. The buyer should specify whether the expected outcome is immediate session revocation, denial at the next authorization check, or a documented expiration window.
Require an evidence pack for each boundary
The report should identify the tested application build and configuration, identity providers, SAML and OIDC flows, SCIM clients, account fixtures, roles, tenant memberships and exclusions. For a finding, require the expected result, observed result, affected account or role boundary, redacted protocol evidence, application impact and remediation guidance. A configuration finding should say which component the buyer controls and who can fix it.
Ask for a coverage matrix that separates federation validation, account binding, local authorization and lifecycle behavior. It should record successful baseline cases as well as denied cases. This prevents a “SSO tested” summary from hiding an untested SCIM client or an untested role transition. If a partner IdP or customer directory was excluded, mark that clearly rather than implying the entire integration was assessed.
Retest evidence should use the same controlled identities, show the fixed application or configuration version, and explain the outcome of the original case and related boundary cases. For products with frequent identity changes, keep the fixture and mapping inventory so a later assessment can repeat the checks. A one-time or annual test and a continuous program serve different release cadences; both should have a defined scope and a reviewable report.
Questions for an identity testing vendor
Which SAML and OIDC profiles and application entry points will be tested?
How will you test issuer, audience, signature, transaction binding and the local account selected after login?
Will you examine the application's own role, tenant and object authorization after a successful login?
Which SCIM clients, resources, attributes and lifecycle actions are in scope?
What identities and directory permissions must the buyer provide for safe testing?
How will you report excluded partner infrastructure and retest results?
The vendor's answer should trace an identity from its source through a local session and finally to the resources it can access. If the plan ends at the login page, it has not addressed the enterprise risk the buyer is purchasing the assessment to examine.
Where Stingrai fits
Stingrai is a CREST-accredited offensive security company. Its web application and API service covers authenticated roles, object and function authorization, and validated request and response evidence. For an identity engagement, provide the SAML, OIDC and SCIM integration map and the expected local account rules during scoping. Stingrai's testing can support a compliance program and produce evidence for an audit while the buyer remains the owner of identity policy and access decisions.
Frequently Asked Questions
What should a SAML, OIDC and SCIM penetration test include?
It should include federated assertion or ID token validation, account linking, local role and object authorization, SCIM client permissions, and the effect of provisioning changes on access. The report should give separate evidence for each boundary.
Is successful single sign-on enough to prove the application is secure?
No. A valid federated login establishes an identity and session, but the application must still select the correct local account and enforce its own roles, tenant rules and object permissions.
Does SCIM replace SAML or OIDC testing?
No. SCIM manages account and group lifecycle, while SAML and OIDC carry federated authentication. Testing one path does not establish that the other path or their account binding is correct.
Why test issuer and subject together in OIDC?
OpenID Connect identifies the stable end user by the issuer and subject combination. Testing that binding helps reveal whether the application could confuse accounts from different identity providers or link them only by a changeable attribute.
What deliverables should procurement request?
Request the integration inventory, test identities and roles, coverage matrix, redacted evidence for accepted and rejected cases, configuration ownership, exclusions, remediation guidance and a retest record tied to the tested version.
Related reading
References
OpenID Foundation, OpenID Connect Core 1.0 incorporating errata set 2.
IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security.
Talk to Stingrai
Bring your federation settings, provisioning flows and local account rules to Get a Quote, or book a free discovery call to define a reviewable identity test scope.
