Testing SSO and SCIM in identity products
An identity product can fail without any error: a deprovisioned user keeps a valid session, token or group membership.
Research desk, cybersecurityqavendors.com. Published 2026-11-11.
Short answer
Test SAML and OIDC login flows including rejected assertions and tokens, SCIM create, update and deprovision against each identity provider you support, revocation of every session and token after deprovisioning, role and group mapping, and an audit entry for every change. Ask a QA vendor for an identity product case that names these flows and the automation it left behind.
SAML and OIDC login
An IAM1 product either acts as the identity provider or trusts one. Its login tests need more rejected cases than accepted ones, because every validation step the product skips lets a forged or stale credential through.
For SAML, test login started by the service provider and login started by the identity provider. Then send assertions that must fail: a missing or invalid signature, a wrong audience, an expired NotOnOrAfter time, an InResponseTo value from another request, and an assertion already used once. Each must be refused and logged.
For OIDC, test the authorization code flow with PKCE, then tamper with the state and nonce values, the token signature, the issuer and the audience. Add an ID token signed with a key the provider has already rotated out.
Clock skew applies to both protocols. Move the test host clock ahead of and behind the identity provider by more than the allowed skew and check that login is refused with an error an admin can act on.
Rotate the provider's signing certificate during a test run. New logins should keep working while both certificates are published, and stop working with the old one once it is withdrawn.
SCIM provisioning
Two identity providers can send the same change as different requests, so run every case against each provider the product supports. Replay recorded request sets per provider, alongside a direct client that covers the protocol's edge cases.
Cover create, read with filters, full replace, partial update with PATCH, deactivation by setting active to false, and delete. Add pagination on a large user list, a create for a user that already exists, a PATCH on a user deleted a moment earlier, and the same request sent twice.
Group tests add and remove members in one request and in many. A group rename should leave its members' access unchanged.
A customer's first sync pushes its whole directory at once. Replay a full directory sync and check that the product returns a retry signal when it hits its rate limit and that no user is left half-created.
Revoking access
- Give one user every kind of access. Log the test user in through SAML and OIDC in two browsers, issue a refresh token, create an API token and add the user to a privileged group.
- Deprovision through SCIM. Send a deactivation from the identity provider, then repeat the whole run with a delete.
- Check each session. Reload every logged-in browser and record when each loses access. Compare the time with the session lifetime your documentation states.
- Check each token. Call the API with the access token, refresh token and API token. Expect the refresh to fail at once, and record how long the access token stays valid.
- Check group effects. Confirm the user is gone from every group and that connected applications receive the removal.
- Reactivate. Re-enable the user and confirm that old sessions and tokens stay invalid while new logins work.
For a PAM2 product, add checked-out credentials and open privileged sessions to step 1. Factor-level cases, such as code replay and recovery, are in testing MFA.
Roles, groups and audit logs
A mapping turns identity provider groups or claims into product roles. Test a user in no mapped group, in two groups that map to conflicting roles, in a nested group, and moved between groups while logged in. Record which role wins in each case and compare it with the documentation.
A changed email, username or department can break the link between the provider account and the product account and create a duplicate user. Test each attribute change through SCIM and through a login that carries the new value.
A customer's security team reads audit logs after an incident. For every SCIM change, admin change and role change, check that one entry records the actor, the target, the old and new values, the time and the source: SCIM, admin console or API. Confirm that an admin of the same tenant cannot edit or delete entries.
What to ask a QA vendor
Ask for a case on an identity, SSO, MFA or PAM product that names the protocols tested and states whether deprovisioning checks were automated. Map the answers to the methodology:
- Dimension 1, evidence depth. A published case on an SSO, provisioning or PAM product counts here; one naming the identity providers and SCIM operations tested shows what the team covered.
- Dimension 3, test-type depth. Protocol flows are API and automation work, so ask which test types the case lists.
- Dimension 4, engagement longevity. Every new identity provider integration adds a request set to maintain, so ask how many provider integrations the vendor's longest identity engagement covered over its lifetime.
- Dimension 6, security posture. Test tenants and signing keys give the vendor admin rights in your identity setup. Request its ISO 27001 certificate reference, and test its exit by deprovisioning its tenant admin accounts with your own product.
The wider set of RFP questions is in RFP questions for a QA vendor.
- 1 IAM: The practice of managing user identities in an organization and deciding which roles and access privileges each person or account gets. Source
- 2 PAM: The discipline of controlling, monitoring and protecting accounts with elevated rights, such as administrators, because they can reach critical systems and sensitive data. Source
Questions buyers ask
What does IAM QA cover?
Login flows for each protocol the product supports, user and group provisioning, access revocation, role mapping, admin actions, audit logs, and the product's behaviour when the identity provider is slow or unavailable.
How do you test SCIM provisioning?
Replay recorded request sets from each supported identity provider, then cover create, filtered read, replace, PATCH, deactivation and delete, plus duplicate requests, pagination, rate limits and changes to users that no longer exist.
Which SAML test cases matter most?
Rejected assertions: a missing or invalid signature, a wrong audience, expired time conditions, a replayed assertion, an InResponseTo value from another request and clock skew beyond the allowed window. Each must be refused and logged.
How do you confirm a deprovisioned user loses access?
Give a test user live sessions, a refresh token and an API token, deprovision through SCIM, then test each one and record when it stops working. Compare the times with the session and token lifetimes in your documentation.
Can IAM product tests be automated?
Protocol flows, SCIM requests and revocation checks run as API tests without a browser. Keep a smaller browser suite for redirects, consent screens and logout across applications.
What should an IAM audit log record?
For each change: who made it, which user or group it affected, the old and new values, the time, and whether it came from SCIM, the admin console or the API.
Should a QA vendor have access to our identity provider tenants?
Give the vendor separate test tenants with synthetic users only, keep signing keys and API tokens in your secret store, and remove the vendor's access with the same deprovisioning steps you test in the product.