OpenID Connect Core, the OASIS SAML 2.0 standard and the SCIM protocol govern different parts of an enterprise identity integration. A successful single sign-on demonstration proves that one user logged in. It does not show that an assertion for another audience is rejected, that a departed user loses access, or that a provisioning event cannot cross a tenant boundary.
Quick answer. Ask for a test matrix that follows an identity from invitation through authentication, authorization, role change and deprovisioning. For each transition, the report should identify the input identity, expected decision, observed decision and evidence of denial or revocation. The matrix below is an original synthesis of the primary SAML, OpenID Connect, OAuth, SCIM and NIST guidance. Stingrai can use it to scope a human-led assessment of the integrations your enterprise buyers actually use.
This reference is for CISOs, identity architects and procurement teams evaluating a SaaS product or commissioning a penetration test. It does not declare that every integration needs every test. An application that has OIDC but no SCIM should mark provisioning rows out of scope. An application that supports several identity providers should identify which providers and tenant configurations were assessed. Such precision makes a pentest report useful to the customer who asked for it.
Why a login test is too narrow
Federated login and account provisioning answer different questions. SAML and OpenID Connect convey authentication information from an identity provider to a relying application. SCIM RFC 7644 defines an HTTP protocol for managing identities such as Users and Groups across domains. After either protocol succeeds, the application still decides which tenant, role and resource the user may reach. The buyer should therefore test the protocol boundary and the product's own authorization boundary.
The standards provide clear anchors. OpenID Connect Core specifies ID token validation, including issuer and audience checks, and exact matching of the registered redirect URI for the authorization code flow. RFC 9700 updates OAuth security advice and requires public clients to use PKCE. The OASIS SAML core specification defines assertions and conditions. NIST SP 800-63C addresses federation and assertions in the current revision of its digital identity guidance. The matrix converts these sources into buying questions and observable evidence; it does not reproduce their full conformance requirements.
Figure 1: The lifecycle stages an enterprise identity assessment should connect. Sources: OpenID Connect Core, SCIM RFC 7644 and NIST SP 800-63C.
The enterprise identity test matrix
Use the “proof to request” column as an acceptance criterion in a statement of work. A denied operation is meaningful only when the tester can show the identity, tenant and current entitlement that made denial the expected behavior. The rows are recommended tests, not verbatim language from the cited standards.
Lifecycle boundary | Test objective | Proof to request | Primary anchor |
|---|---|---|---|
Federation configuration | A tenant cannot redirect authentication to an unapproved identity provider | Configuration and observed rejection of the unapproved issuer | |
SAML assertion | The application binds an assertion to its intended service provider and valid conditions | Redacted assertion metadata and acceptance or rejection decision | |
OIDC issuer | A token from another issuer is not treated as a session for this tenant | Redacted issuer claim and rejection result | |
OIDC audience | A token intended for another client is rejected | Redacted audience claim and observed application decision | |
Redirect binding | Login cannot complete through an unregistered callback | Registered URI, attempted alternative and rejection result | |
Authorization code protection | The applicable OAuth client uses transaction-bound code protection | Configuration review and a safe negative test of code misuse | |
Tenant selection | The identity is mapped only to the enterprise tenant that owns the relationship | Tenant mapping, permitted session and denied cross-tenant session | |
Provisioning creation | A SCIM-created user receives only the requested organization and role | Provisioning event, resulting account state and permissions | |
Group update | A group change cannot silently grant a higher application role | Before and after entitlement view with expected policy | |
Deprovisioning | Compare account state and new login behavior with the deprovisioning rule; test existing sessions against the documented revocation window | SCIM event, account state, new sign-in result and observed session timing | |
Existing sessions | Role or account removal affects already issued sessions according to the product policy | Policy, timing observation and denial result | |
Audit trail | A change can be attributed to the correct identity provider, tenant and account | Correlated event records with sensitive fields redacted | Buyer evidence request |
The protocol does not decide every application behavior. A vendor may choose a bounded period before a session expires after deprovisioning, subject to the customer's policy. The assessment must document the policy first, then test whether the implementation meets it. A report that labels every surviving session a vulnerability without understanding the contract can mislead the buyer; one that ignores the issue can do the same.
Supply the right test identities
Give the assessor at least two test organizations with separate identity provider configurations when the product supports multi-tenancy. Within each, prepare ordinary and privileged users, a user with a delegated role, and an account that will be disabled during the test. Provide a provisioning client in a controlled environment and a safe rollback plan. If production testing is required, agree on synthetic users and a window that will not affect real employees.
An architecture map is equally valuable. Show the identity provider, application callback, API gateway, session store, SCIM endpoint and downstream services that consume group or role information. Name the point where a SAML assertion or ID token becomes an application session, and where that session becomes an API authorization decision. The handoff between these components is where a correctly validated upstream token can still lead to excessive downstream access.
Ask the product owner to write the expected result for each identity transition. For example: which roles may invite users, whether an identity can belong to several tenants, what happens after a group removal, and whether deprovisioning revokes active API tokens. Those choices are product policy, not facts the penetration tester should invent. NIST SP 800-63C supplies a framework for federation assurance, but the organization still must define its application-specific entitlement rules.
What to demand in the report
A useful report is organized around control decisions, not around screenshots of a login page. It should state the configurations tested, the identity provider type, the protocol flow, test accounts and excluded paths. For each confirmed issue, request the actor and target, expected behavior, observed behavior, business impact, safe reproduction evidence, remediation advice and a retest result. For passed controls, a concise coverage table with representative denied outcomes is enough.
Provisioning deserves its own evidence. A SCIM success response does not prove that the product assigned the right role or removed an old session. Ask for the downstream application state after creation, update and deprovisioning. Compare the SCIM event with what the affected user can still do in the UI and API. RFC 7644 describes the protocol's identity-management operations; the application's entitlement and session behavior must also be assessed.
The report should distinguish an exploitable access-control problem from a configuration choice that needs a risk decision. It should record any limitations caused by missing accounts, inaccessible identity provider settings or a blocked test window. That candor is particularly important for an enterprise buyer who will read the executive summary without seeing the underlying test environment.
How to buy the right assessment
Send this matrix with the identity architecture diagram and ask each bidder to mark the rows included in its quote. Ask whether the test includes the application, the identity provider configuration, SCIM lifecycle, API authorization after login and post-remediation retesting. Confirm who supplies provider access and who approves safe negative tests. If the product has both SAML and OIDC, make the vendor say whether both are included.
Stingrai's Enterprise scope includes SSO and API coverage as part of a custom program. A human-led assessment can connect federation behavior to application roles and protected resources, with findings and retests delivered through Stingrai's penetration testing service. For a scoped discussion, send your integration diagram through Get a Quote. A one-time engagement or a continuing program can be proposed against the same written acceptance criteria.
Reuse and citation
This is Stingrai's original test-design synthesis, not a certification checklist. If it informs your article, buying guide or request for proposal, cite and link to Stingrai, “Enterprise Identity Test Matrix 2026,” 15 October 2026. The linked standards remain the primary sources for their protocol requirements.
Frequently Asked Questions
What should an enterprise SSO penetration test prove?
It should prove that the application accepts only the intended identity provider, validates the relevant assertion or token, maps the user to the correct tenant and role, and enforces access after login. The report should also document what happens after a role change or deprovisioning. Stingrai can scope human-led testing around those transitions and the API permissions they create.
Is a successful SAML or OIDC login enough evidence?
No. A successful login demonstrates one allowed path. It does not demonstrate rejection of a token for another audience, a wrong issuer, an unapproved callback or an account that should have lost access. Ask for safe negative tests and the resulting decision evidence.
Why include SCIM in the assessment?
SCIM can create, update and remove enterprise identities and groups. A provisioning error can assign the wrong application role or leave access in place after an account is disabled. Test the downstream application state and sessions, not only the SCIM HTTP response.
Does NIST SP 800-63C require this exact matrix?
No. NIST SP 800-63C provides requirements and guidance for federation and assertions. This matrix is Stingrai's editorial synthesis that turns relevant protocol boundaries into buyer-facing test objectives. The application owner must decide which rows apply and what its access policy requires.
Should identity and API authorization be tested together?
Yes, when the product turns a federated identity into API permissions. A correctly validated login can still map to the wrong tenant, role or protected record. The statement of work should include a post-login authorization check for the application's highest-value workflows.
Related reading
References
Talk to Stingrai
Share your identity architecture and the rows that matter to your customers through Get a Quote, or book a free discovery call to define a human-led assessment.
