Authentication, SSO and OAuth testing

Why authentication and SSO testing is a separate engagement

This test checks whether login, MFA, password reset, session handling and SAML, OAuth 2.0 and OpenID Connect flows hold up, measured against ASVS chapters V6 (Authentication), V7 (Session Management), V9 (Self-contained Tokens) and V10 (OAuth and OIDC). It is most often commissioned when a team is replacing its identity provider, adding SSO for the first time, or when a framework assessor or a customer security review names authentication directly. Identity is the layer that decides who can reach everything behind it, so it is worth testing on its own rather than as a line item in a broader web test. The risk categories are A07 Authentication Failures in the OWASP Top 10 2025 and API2 Broken Authentication in the OWASP API Security Top 10 2023. Both cover weak credential handling, flawed token validation and session weaknesses that let an attacker act as another user.

General web application tests often under-cover identity flows for practical reasons. Authentication is usually exercised once, with a single test account, while the risk sits in the variations: the redirect URI registration, the handling of the state and nonce parameters, how the relying party validates the ID token audience and issuer, what happens when a second factor is skipped or replayed, and whether a password reset link survives a change of credentials. Those checks need a tester who understands the protocol and has the identity provider configuration in front of them. Before commissioning, confirm with the team which identity provider and protocol versions are in use, which grant types and client types are enabled, and whether the test environment mirrors the production tenant settings. Those answers decide whether the engagement needs documentation-led access as ASVS 5.0.0 encourages.

Separate scoping also changes the report. An ASVS verification report lists the requirements checked, the exceptions and the requirements that do not apply, which is the form many assessors and customers ask for. Expect the engagement to need a named set of roles, such as an end user, an administrator and a user from a second tenant or organization, so that cross-account and privilege escalation paths can be tested. Ask any provider to state in writing which ASVS level they will verify against and how they will treat federated sessions, token lifetimes and account recovery, because those decisions define what the final evidence actually proves.

What can be in scope for an identity test

An identity test covers more than the login form. The components below connect to one another, so scope decisions about tenants, accounts and lockout rules should be made once, in writing, before testing starts. Each card names a component or decision that changes what the test covers and what it costs.

Login, MFA and step-up flows

Login pages, MFA enrolment, MFA challenges and step-up prompts for sensitive actions are the first component most teams expect to see tested. Testers check whether MFA can be skipped by navigating directly to post-login pages, whether enrolment can be completed by an attacker with only a password, and whether fallback methods weaken the factor. Confirm which MFA methods are in use and whether the test account can enrol a device.

Password reset and account recovery

Reset links, one-time codes, security questions and support-assisted recovery often sit outside the main login path and receive less review. Testing looks at token entropy, expiry, single use, whether reset tokens leak through referrers or logs, and whether recovery changes the account's MFA state. Ask the client to list every recovery route, including helpdesk or self-service channels.

Session lifecycle

Session handling covers how a session is created, rotated after login and privilege change, expired after inactivity, and terminated on logout or password change. Testers verify that cookies carry the expected attributes, that old sessions are invalidated, and that concurrent sessions behave as the business expects. Agree in advance whether session tokens for test accounts may be revoked during testing.

SAML and OIDC relying parties

The application acting as a SAML service provider or OIDC relying party must validate assertions and ID tokens correctly. Testing covers signature checks, audience and issuer validation, nonce and state handling, clock tolerance, and whether the application maps identity claims to local accounts safely. Provide the metadata, the expected claim set and the list of accepted identity providers so the tester can check each assumption.

OAuth clients and token endpoints

OAuth clients, redirect URIs, grant types, scopes and token endpoints define what a token can do and where it can go. Testing checks redirect URI matching, PKCE use for public clients, token lifetime, refresh token rotation, and whether scopes are enforced by the resource server. Obtain the client registration list and confirm which grant types each client is permitted to use.

Identity provider configuration

Many findings sit in the identity provider rather than the application, such as permissive redirect URIs, weak password policy, unused admin consoles or disabled MFA for a legacy client. Decide whether the provider is in scope in full, only the settings that the application depends on, or not at all. A provider-level review needs written permission from whoever operates that platform, and it is often a separate engagement from the application test.

Tenants, environments and test accounts

Scope must name the tenants, environments and identities the test may use. Teams often need separate accounts for each role, plus one account that is deliberately unprivileged and one that holds MFA enrolments the tester can use. Confirm whether production identities are available, whether test users can be created and deleted, and who owns the approval for each account.

Rules of engagement for lockout and MFA

Brute-force protection and MFA rate limits are the two controls most likely to disrupt live users during testing. Agree the maximum login attempts per account, the lockout window to be observed, who unlocks accounts, and whether MFA prompts may be triggered repeatedly. Record a contact who can stop testing immediately and a time window when testing should avoid peak authentication load.

How an authentication and SSO engagement runs

The sequence turns a login, MFA, reset, session and SSO design into a tested set of findings, each tied to the ASVS requirements it affects and to a clear retest outcome. Each step closes with a written output so the client can see what was checked and what remains open.

Agree the written scope and test accounts
The client and DeployOpen agree in writing which applications, tenants, identity providers, relying parties, login journeys and environments are in scope, and which are excluded. The client supplies test accounts for each role, MFA enrolment for those accounts, and a named contact who can approve testing windows. The step closes when the scope document lists every flow to be tested, the account matrix and the rules of engagement, and both parties have signed it.
Collect documentation and source access
The client shares architecture diagrams, identity provider configuration exports, SAML metadata, OAuth client registrations, redirect URI lists, token lifetimes, and the intended login and recovery flows. Where the client agrees, testers also read the relevant authentication and session code. ASVS 5.0.0 favors this documentation or source led (hybrid) approach because many requirements on business logic and access control cannot be confirmed from outside the application. The step closes with a documented baseline that states what was received and what was not.
Map flows to WSTG and ASVS requirements
DeployOpen maps each in-scope flow to the WSTG identity management, authentication and session management categories and to ASVS chapters V6 Authentication, V7 Session Management, V9 Self-contained Tokens and V10 OAuth and OIDC. The map records which requirements apply at the client's chosen verification level, which do not apply and why. The step closes with a test plan that the client can read against its own control list before testing begins.
Test authenticated and unauthenticated paths
Testers exercise login, MFA enrolment and challenge, password and account recovery, lockout behavior, session creation, rotation and termination, and each SSO handoff as both unauthenticated and authenticated users. For SAML, OAuth 2.0 and OpenID Connect, the work covers how the relying party validates assertions, state, nonces, redirect URIs, audiences and tokens. Automated tools support this work but do not replace it, since ASVS 5.0.0 notes that DAST and SAST tools cannot fully verify many business logic and access control requirements. The step closes with a test log linking each check to its requirement and result.
Validate and rate findings
Each suspected weakness is reproduced under controlled conditions, confirmed against the relevant requirement, and rated with the client using its own risk method. Testers record the affected flow, the account and role involved, and the conditions needed to trigger it. Findings that depend on a configuration choice in the identity provider are flagged so the client can confirm them against its own environment. The step closes when every finding has a status of confirmed, not reproduced or needs client input.
Deliver the report and evidence
The client receives a report that lists the scope, the requirements checked, the requirements with exceptions and guidance on fixing them, and the requirements marked as not applicable. This differs from a traditional penetration test report, which lists issues by exception. The report is designed to serve as input to the client's own assessor, who decides what it means for any certification. The step closes with a readout where the client's engineers and the DeployOpen testers walk through each finding.
Retest fixes and close the record
After the client applies fixes, testers repeat the original checks against the changed flows and record whether each finding is resolved, partly resolved or still open. Retest scope and any fee are agreed in writing, and the client should confirm whether a retest is included in the original scope. The step closes with an updated report that shows the status of every finding and the requirements that now pass.

Where SSO and OAuth integrations usually break

Most SSO and OAuth failures are not exotic. They come from a few categories that recur whenever an identity provider changes or a new application joins the login flow. The first is token and assertion validation: the relying application must check the issuer, audience, signature, and expiry on every token or SAML assertion it accepts, and must reject anything that fails. In a test, confirm that the application validates each of these claims against the identity provider's configured values, that it does not fall back to decoding tokens without verification, and that it refuses assertions or tokens issued for a different client or audience. The second is redirect URI and state handling. Exact-match redirect URI registration, a single-use state value bound to the user's session, and strict handling of errors on the callback are the controls to check, along with whether any open redirect on the application could be chained into the flow.

The third category is client type and PKCE. Public clients such as single-page and mobile apps cannot keep a secret, so the authorization code flow should use PKCE, and the identity provider should enforce it for those clients. Confirm which grant types each client registration allows, and remove implicit or password grants that are no longer needed. The fourth is account linking. When a user can sign in with more than one provider, the application must link identities by a stable, provider-scoped subject identifier, not by an email address the user may be able to change or that a provider may reassign. Mismatched linking is a common route to account takeover across tenants. The fifth category is MFA and recovery. MFA bypass usually happens through an alternate path: a legacy login endpoint, an API that accepts a password without the second factor, or a "remember this device" token that outlives its intended scope. Password reset and account recovery flows can undo MFA entirely if they sign the user in without the second factor. Session fixation and lifetime, covering whether the session identifier rotates at login and how long idle and absolute timeouts last, complete the list.

These categories map to ASVS chapters V6 (Authentication), V7 (Session Management), V9 (Self-contained Tokens) and V10 (OAuth and OIDC), and most of them cannot be proven by a scanner. Whether a relying party accepts a forged or mis-audienced token depends on the application's own logic, which is why the authenticated, documentation-led test matters. CIS Safeguard 16.13 favors authenticated penetration testing for business logic in critical applications, with testers acting as both authenticated and unauthenticated users, and that is the right model for SSO flows that span several services. Before you commission the work, confirm that the tester will receive the identity provider configuration, the client registrations, the expected claim mappings and test accounts for each role and provider, so each category above can be checked against a documented expectation.

Weakness categories in login, SSO and OAuth flows

This table lists the weakness categories a focused authentication test examines, what each looks like in login, SSO and OAuth integrations, why it matters, and the ASVS chapter or OWASP item it maps to. Use it to check whether a proposed test scope covers the flows your identity change touches.

Weakness category	What it looks like in this target	Why it matters and where it maps
Token validation	Relying parties accept ID tokens or access tokens without checking signature, issuer, audience, expiry or nonce, or accept unsigned or algorithm-switched tokens	Forged or replayed tokens grant access. Maps to ASVS V10 OAuth and OIDC and OWASP A07 Authentication Failures
Redirect and state handling	Loose redirect URI matching, open redirects on login callbacks, or missing or reusable state and PKCE parameters in authorization flows	Authorization codes can be intercepted or redirected to attacker-controlled endpoints. Maps to ASVS V10 and OWASP A01 Broken Access Control
MFA enforcement and fallback paths	Second factor skipped on alternate routes such as legacy endpoints, API logins, SSO bypass accounts or 'remember this device' logic	Strong primary login is undone by a weaker path. Maps to ASVS V6 Authentication and OWASP A07
Password reset and account recovery	Reset tokens that are predictable, long-lived, reusable or not bound to the account, and recovery questions or email changes that skip re-verification	Account takeover without the primary credential. Maps to ASVS V6 and OWASP A07 Authentication Failures
Session lifecycle	Session identifiers not rotated at login, sessions surviving logout or password change, and weak timeout or cookie attributes	Stolen or fixated sessions remain valid. Maps to ASVS V7 Session Management and OWASP A07
Account linking	Federated identities linked to existing local accounts by unverified email address, or linking that a user can trigger without re-authenticating	Attacker-controlled identity attaches to a victim account. Maps to ASVS V10, OWASP A01 and API2:2023 Broken Authentication
Claim mapping and authorization	Roles, groups or tenant identifiers taken from token claims without validation, or mapped so that a user gains privileges after an IdP change	Users receive access they should not hold. Maps to ASVS V8 Authorization, OWASP A01 and API5:2023 Broken Function Level Authorization
Trust of identity provider settings	Metadata, signing certificates, discovery URLs or allowed issuers set once and never reviewed, or tenant-wide trust that accepts any IdP	A change or compromise at the provider propagates into your application. Maps to ASVS V10, OWASP A02 Security Misconfiguration and API8:2023

How identity testing differs by architecture

A single application with its own login keeps identity logic inside the codebase the client owns. The test covers registration, credential storage, login throttling, MFA enrollment and verification, password reset, account recovery and session issuance and termination. Because the application makes every decision, the tester can follow each flow end to end, and ASVS chapters V6 (Authentication), V7 (Session Management), V9 (Self-contained tokens where used) and V10 (OAuth and OIDC, if any) map directly onto the code paths.

Account lifecycle: registration, email verification, reset tokens and account lockout are tested as one set of state transitions.
Credential handling: storage, hashing approach and transmission are reviewed, often with source access.
MFA bypass paths: fallback methods, recovery codes and step-up flows are checked for weaker routes around the primary factor.
Session lifecycle: issuance, rotation after login, idle and absolute timeouts and logout invalidation are verified.
Test accounts: the client provides at least one account per role and a documented way to reach each reset or MFA step.

Confirm with the client whether source code and architecture documents are available, because ASVS favors documentation-led testing over black-box guessing for this architecture.

Frameworks that expect authentication testing

This table compares the frameworks and verification standards that most often ask for testing of login, session, and identity flows, and what each one expects as evidence. Use it to see which requirement applies to your scope, then confirm the exact wording and evidence format with your assessor before you commission work.

Framework or standard	What it expects for authentication testing	Evidence an assessor usually looks for
PCI DSS 11.4.1	Application-layer penetration testing that covers, at minimum, the vulnerabilities listed in 6.2.4, including abuse of business logic and manipulation of APIs in login and account flows	Scope statement covering authentication endpoints, findings with retest records, and tester qualifications; confirm with your assessor
CIS Safeguard 16.13	Application penetration testing for critical applications, where authenticated testing as both logged-in and anonymous users is better suited to finding business logic flaws than automated scanning alone	Test plan showing authenticated and unauthenticated roles, test accounts used, and business logic cases covered
ASVS V6 Authentication	Verification of password and credential handling, multi-factor authentication, account recovery and lockout behavior	Requirement-by-requirement results with exceptions, plus notes on requirements that do not apply
ASVS V7 Session management	Verification that session tokens are generated, bound, expired and invalidated securely across login, logout and privilege changes	Session lifecycle test results covering timeout, logout and re-authentication after sensitive changes
ASVS V9 Self-contained tokens	Verification that signed tokens such as JWTs are validated correctly for signature, issuer, audience and expiry	Token validation test cases and evidence that the verifier checks algorithm, key and claim handling
ASVS V10 OAuth and OIDC	Verification of redirect URI handling, PKCE use, scope limits, token storage and consent in OAuth 2.0 and OpenID Connect flows	Flow-by-flow test notes for each client and authorization server, with the configuration reviewed
ASVS verification report	A report that lists scope, all requirements checked, exceptions and guidance, which differs from a penetration test report that lists issues only	Verification report structure agreed before testing; ASVS does not certify verifiers, so ask for the tester's own evidence of method
Your auditor or customer	Specific wording on which SSO, MFA or reset flows must be tested and how often	Written confirmation of the requirement, scope and acceptance criteria before work starts

What the client receives and whether it satisfies an auditor

An issues-by-exception penetration report and an ASVS verification report answer different questions, and the difference matters once a customer or auditor asks for evidence. The cards below cover what a authentication, SSO and OAuth engagement should contain and how each part is checked before it is used as evidence.

Scope and requirement coverage

The report should state the applications, identity flows, tokens, environments and ASVS level tested, along with the test accounts and roles used. For this topic that means naming the login, MFA enrollment, password reset, session and SSO paths, and the identity provider and relying party configurations in scope. Ask the provider to confirm which ASVS chapters are covered, including V6, V7, V9 and V10, so the boundary is written down before testing starts.

Summary of every requirement checked

An ASVS verification report lists every requirement in scope with its result, not only the failures. A reader can see that a password reset token expiry check passed as well as the requirements that did not. Auditors and customer security teams use this complete list to judge coverage, so a report that only shows findings leaves them unable to see what was tested.

Exceptions and remediation guidance

Each requirement with an exception should have a description of the observed behavior, the affected flow, and guidance on how to resolve it, such as how OIDC token validation or MFA step-up should be configured. The fix guidance should be specific enough that the engineering team can act on it without a second call. Ask whether guidance references the identity provider's own documentation where a configuration setting is the cause.

Not applicable decisions

Requirements that do not apply, such as SAML requirements on an OIDC-only application, should be listed with the reason. A justified not applicable entry is accepted by most assessors, while an unexplained gap is not. Ask for the rationale to be tied to the architecture described in scope, so the same reasoning survives an audit cycle.

Severity and reproduction context

Each finding should carry a severity rating with the reasoning behind it, and enough reproduction context for an engineer to confirm the issue: the flow, the account role, the relevant request and response details, and the conditions under which it occurs. The report should describe the weakness category without including working exploit steps or payloads that would be unsafe to circulate.

Retest results and acceptance

A retest confirms which exceptions were closed, and the updated report should record each requirement's new status with the date and the build or configuration retested. Whether this evidence satisfies an auditor or customer is decided by that party, not by the tester or by DeployOpen. Confirm with your assessor or customer in advance what they will accept, and whether an independent verifier is required for the ASVS report.

What the client prepares before testing starts

The most useful thing a client can do before an authentication test is provide dedicated test tenants and test accounts for every role the application recognizes, such as standard user, administrator, support agent and any tenant or organization owner. Each role needs its own identity so the tester can check whether one role can reach another role's functions, objects or sessions. Test accounts must not be production users. A tester who logs in with a real employee or customer account can lock that person out, trigger real notifications, change real data, or cause fraud alerts that the security operations team then has to investigate. Ask the identity team to create the accounts in a non-production identity provider tenant or in a segregated realm, with synthetic email addresses and no access to real business systems beyond what the test requires.

Plan MFA enrollment for those accounts in advance. For each role, decide which second factors are in use (for example, time-based one-time passwords, push approval or passkeys) and enroll them on the test identities before the test window opens, so the tester is not blocked waiting for a device. Also agree how the tester will test step-up authentication and recovery paths, since these are where many authentication flaws sit. Provide the identity provider configuration in writing: an export or documentation of the SAML entity IDs and assertion settings, OAuth 2.0 and OpenID Connect client registrations, allowed redirect URIs, scopes, token lifetimes, signing algorithm settings and any attribute mappings. Without these, the tester has to reverse-engineer the trust relationship, which is slower and more likely to miss a weak configuration. Confirm with the vendor's documentation which of these settings are exposed in your version and what the export format is.

Document the lockout and rate-limit policies that apply to login, MFA challenges and password reset, including thresholds, lockout duration and any CAPTCHA or adaptive controls. Testers need this to decide how to probe for brute-force and enumeration weaknesses without locking out the whole test population, and to tell a control that works from one that is absent. Name one person who can unlock test accounts, reset their factors and answer questions during the test window, and agree how they will be reached outside business hours if testing runs long. Finally, ask the identity team for a change freeze on the identity provider, its client registrations and the affected applications for the test window. A configuration change mid-test invalidates findings and can make a fixed issue look open or the reverse. Record the freeze dates in the statement of work so that any exception is a documented decision, not a surprise.

Questions buyers ask before commissioning identity testing

How much does authentication and SSO testing cost?

The cost depends on the written scope, so there is no standard figure to quote here. The main drivers are how many login paths exist (password, MFA, social or enterprise SSO, API tokens), how many identity providers and client applications are in scope, whether the tester receives documentation and source or works blind, and how many test accounts and roles must be exercised. Most engagements are fixed-scope, so the quote follows from a written scope agreed before work starts. Ask for the quote to separate the test itself, the report, and any retest, and to state which items are one-time and which recur if you run continuous testing as a retainer.

How long does an identity testing engagement take?

Duration follows from the scope, so ask for a timeline in the written proposal rather than relying on a general estimate. Time goes to mapping each authentication flow, setting up accounts and roles, testing MFA enrollment and recovery, reviewing token and session behavior, and writing findings. SSO integrations take longer when SAML assertions, OAuth grant types and OpenID Connect claims must each be checked against the relevant ASVS requirements in chapters V6, V7, V9 and V10. Delays often come from waiting for test tenants or client credentials, so confirm those dates before the test window is set.

What does the client need to provide for the test?

The tester needs enough access to test the flows as real users and administrators would use them, and enough documentation to avoid guessing. Typical inputs are a staging or pre-production environment that mirrors production identity settings, test accounts for each role, configuration details for the identity provider and relying parties, redirect URI and scope lists, and the MFA methods in use. Ask the provider to list every input in the scope document, including who on your side approves account creation and who handles lockouts during testing. OWASP ASVS 5.0.0 favors documentation or source led testing, so sharing architecture notes and token lifetimes usually produces more useful findings.

Can our internal team test authentication and SSO itself?

Internal teams can run useful checks, such as reviewing configuration against the identity provider's hardening guidance, validating session lifetimes, and running regression tests on login flows. An independent test is different, because the people who built the integration tend to test the paths they expected. Automated DAST and SAST tools cannot fully verify many requirements, especially those about business logic and access control, so a manual review by a tester outside the build team is usually needed for compliance evidence. A common split is internal checks between releases and an external test before a major identity change.

Does ASVS V6 and V10 coverage satisfy a customer security review?

It depends on what the customer asks for and how the evidence is written. OWASP does not certify vendors, verifiers or software, so no test can be presented as ASVS compliant by OWASP itself. ASVS 5.0.0 says an ASVS verification report should list the scope, summarize every requirement checked, record exceptions with guidance, and note requirements that do not apply, which differs from a penetration test report that lists issues by exception. Confirm with the customer whether they want a report mapped to specific chapters and levels, and whether they accept an independent verifier's report. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports and attestations.

Does an identity provider upgrade need a retest?

A change to the identity provider, its protocol settings, or the relying applications can alter authentication behavior, so a retest of the affected flows is usually the safer option. Examples include moving to a new OpenID Connect provider, changing SAML signing or encryption settings, altering token lifetimes, or enabling a new MFA method. The risk is highest where redirect handling, token validation, or account linking changed. Agree in advance which flows a targeted retest covers and which need the full scope again, because a narrow retest after a major migration can miss regressions in unchanged paths.

How is a retest priced after the first engagement?

A retest is normally scoped separately from the original test, based on which findings are being verified and how much of the application the fix touches. The original quote should state whether a retest is included, how many rounds are covered, and how a retest is billed if fixes change more flows than expected. Ongoing checks after fixes can be arranged as a retainer, which covers recurring work such as support, upgrades and continuous testing, while the retest itself is a defined piece of work. Ask for a retest estimate in the proposal so the cost is known before the first engagement closes.

What to check when choosing an identity testing provider

Identity testing covers login, MFA, password reset, sessions and SSO trust relationships, so a provider needs more than general web testing skills. The cards below set out the decisions a buyer should make and the claims they should verify before signing a written scope.

Protocol depth across SAML, OAuth and OIDC

Ask whether the provider tests SAML assertions, OAuth 2.0 authorization flows and OpenID Connect token handling, not only the login page. Each protocol has its own trust decisions, such as how redirect URIs, audience values and signature validation are enforced. Ask for named examples of each protocol in past work, described at a general level, and confirm how they test with both documentation and authenticated accounts.

Experience with your identity platform

A provider familiar with your identity platform will know where configuration drifts from vendor hardening guidance, such as realm settings, token lifetimes, client registrations and federation brokers. Ask which identity products they have tested, which versions they worked with, and how they keep current with each vendor's security documentation. Confirm that the team assigned to your test has this experience, not only the account lead.

ASVS-mapped reporting

Ask for a report that maps findings and checks to the authentication, session management, access control and OAuth chapters of ASVS, not a list of issues alone. A verification report should state scope, summarize every requirement checked, record exceptions with remediation guidance and note requirements that do not apply. Ask for a sample redacted report before you commit.

Accreditation claims to verify directly

CREST's OVS accreditation assesses whether a testing organization can run web application assessments against ASVS, at Levels 1 and 2. Treat any accreditation claim as a statement to check on the accreditor's own register, not a document the provider sends you. Confirm the accreditation covers the test type you need and the level you specify, and remember that OWASP does not certify vendors or verifiers.

Written scope before testing starts

Identity tests depend on exact boundaries: which tenants, realms, applications, identity providers, test users and MFA methods are in scope, and whether social logins or third-party IdP accounts are excluded. Ask for a written scope that lists these items, the verification level, the authenticated roles to be tested and the production or non-production target. Unclear scope is the most common source of cost changes mid-engagement.

Retest terms and included fixes

Identity findings often require configuration changes in the identity provider and in each relying application, so the retest must cover both. Ask whether one retest round is included, how long after the report it must be requested, whether the retest is written into the original scope, and whether the retest report updates each ASVS requirement status. Ask who performs the retest and whether they are the same testers.

How retesting works after identity fixes

A retest confirms that the findings from an authentication, SSO or OAuth test were fixed, and it checks the fix against the same ASVS requirements that produced the finding. The retest should map each closed finding back to its requirement ID in chapters V6 (Authentication), V7 (Session Management), V9 (Self-contained tokens) and V10 (OAuth and OIDC), so the client can show an auditor or customer that the requirement now passes, not merely that a ticket was closed. Agree in writing which findings are in the retest, how many verification rounds are included, and whether the tester will re-run the authenticated and unauthenticated paths used in the original test. Also confirm whether a retest is billed as part of the original fixed-scope engagement or as a separate piece of work.

Identity changes often create new attack surface even when the original findings are closed. Switching identity providers, adding a SAML or OpenID Connect integration, or changing token lifetimes can alter redirect URI handling, state and nonce validation, audience checks, logout behavior and how sessions survive a password change. Plan a targeted retest of the identity flows you changed, even if the original report contained no findings in those areas. Confirm with your identity team which clients, realms, tenants and test accounts will be live during the retest, and whether the retest environment matches production configuration closely enough to be meaningful.

Some teams need validation after every release rather than once per project. Continuous testing and ongoing support are available as a DeployOpen retainer, which can keep authentication and SSO flows under regular review as the identity configuration changes. Whether a retainer fits depends on how often your identity configuration changes and who approves new integrations. Ask for the retest limits in the written scope, including what counts as a regression, what happens if a fix introduces a new issue, and how long you have to request a retest after the report is delivered.