Authentication Testing
Authentication Testing That Proves Every Identity Transition
A lifecycle guide for proving identity, factors, sessions, protected access and termination across browser and backend layers.
Authentication testing is not a login-form check. It is proof that each transition from claimed identity to protected access and session termination creates only the intended state.
A user can enter valid credentials and still reach the wrong account. An MFA code can be accepted for the wrong challenge. A browser can show a dashboard while the backend session belongs to another tenant. A logout page can appear while the old token still accesses protected APIs.
A complete authentication strategy therefore tests one connected system:
identity claimed-> authenticator verified-> additional factor completed when required-> session created or elevated-> protected access granted-> session maintained within policy-> session expired, revoked or terminated
This guide explains how to model that lifecycle, choose evidence for each transition, prioritise risk and divide detailed coverage across login, MFA, session-management and logout test suites.
Authentication Testing in One Model
The central object under test is not the login page. It is the authenticated state and every transition that can create, strengthen, maintain or destroy it.
| Transition | Question the test must answer | Strong evidence |
|---|---|---|
| Identity claimed | Which account, tenant or subject is the user attempting to become? | Submitted identifier and resolved account record |
| Authenticator evaluated | Was the intended credential or authenticator accepted under the correct policy? | Authentication response, attempt state and identity result |
| Additional factor requested | Was MFA required for the correct account, risk level and operation? | Challenge owner, factor and pre-MFA session state |
| Proof accepted | Did the proof satisfy only the intended challenge and become unusable when policy requires? | Challenge state, consumption and assurance result |
| Session created | Was a fresh session bound to the intended identity, tenant and assurance level? | Session identifier, account mapping and protected API result |
| Protected access granted | Can the user access only the resources permitted for the resulting authenticated state? | Representative protected requests and final identity |
| Session maintained | Do timeout, renewal, remember-me and reauthentication rules preserve the intended assurance? | Timer, token rotation, session store and browser state |
| Session terminated | Does expiry, revocation or logout make the old state unusable everywhere? | Old-token replay, tabs, devices and protected APIs |
Define the Authentication Acceptance Contract
Before writing test cases, document the policy that turns an authentication result into an accepted or rejected state.
| Contract area | Questions to resolve |
|---|---|
| Identities | Which account states, tenants, roles and identity providers exist? |
| Entry points | Which password, SSO, magic-link, passkey, API, recovery and mobile paths can create authentication? |
| Authenticators | Which passwords, OTPs, TOTP apps, push prompts, keys or federated assertions are accepted? |
| Assurance | Which actions require primary authentication, MFA or recent step-up authentication? |
| Attempts | Which rate limits, lockouts, cooldowns and notifications apply? |
| Errors | Which messages are generic, which are actionable and which state is preserved after failure? |
| Sessions | When is a session created, rotated, renewed, expired or revoked? |
| Destinations | Which route, tenant and account should load after each successful path? |
| Recovery | How can users regain access without creating a weaker authentication route? |
| Termination | Which sessions, tabs and devices must stop working after logout or a security event? |
| Evidence | Which browser, API, provider, identity-store and session-store observations prove the result? |
Example authentication acceptance contract
| Input state | Expected transition | Expected protected result |
|---|---|---|
| Valid password, no MFA required | Credentials accepted and fresh session created | Correct user and tenant reach the permitted destination |
| Valid password, MFA required | Restricted pre-MFA state and challenge issued | Protected resources remain unavailable until the factor succeeds |
| Valid MFA proof for another user or challenge | Proof rejected | No session elevation |
| Expired or revoked session | Old state rejected | Protected APIs return no sensitive data |
| Successful step-up for one action | Assurance raised for intended scope | Only the intended action or session gains permission |
| Logout requested | Server-side session terminated | Old browser, API and tab requests fail |
Map Every Authentication Entry Point
Authentication defects often survive because teams test the main login form and forget a secondary route that creates the same protected state.
| Entry point | Questions to test |
|---|---|
| Username and password | Credentials, enumeration, rate limiting, account state, destination and session creation |
| Email or SMS magic link | Recipient binding, expiry, one-time use, host, device or transaction policy |
| SSO / OpenID Connect | Provider response, state/nonce, account linking, tenant mapping and relying-party session |
| SAML | Assertion validation, audience, recipient, replay, account mapping and local session |
| Passkey / WebAuthn | Challenge, relying-party binding, user verification and fallback policy |
| MFA challenge | Challenge ownership, factor delivery, proof validation, replay and session elevation |
| Password reset or account recovery | Identity verification, token lifecycle, factor replacement and session revocation |
| Remember me | Persistent evidence, account binding, expiry, revocation and assurance level |
| Mobile or alternative channel | Equivalent policy, shared identity state and weaker-channel bypass |
| Administrative or support flow | Reset authority, approval, audit trail, notification and affected sessions |
For each entry point, record the same outputs: final identity, tenant, assurance level, session identifier and accessible protected resources. Differences should be intentional, not accidental.
Test Primary Authentication
Primary authentication verifies the first authenticator and establishes the account state from which the rest of the lifecycle continues.
- verify valid and invalid credentials without relying only on a success message
- assert the final identity, tenant and destination after success
- test disabled, locked, suspended, unverified and deleted account states
- compare error text, status codes and timing for valid and unknown identities
- verify attempt counters, cooldowns and recovery after lockout
- test Back, refresh, duplicate submission, concurrent tabs and repeated requests
- confirm that authentication rotates or safely creates the session identifier
- verify that protected routes remain unavailable after failed or incomplete authentication
Use the detailed Login Page Test Cases guide for the complete credential, account-state, redirect, tenant, accessibility and recovery matrix.
Test MFA and Step-Up Authentication
MFA is not proven when a correct code is accepted. The proof must belong to the intended identity, challenge, factor, session and operation.
- verify that MFA is triggered at every required entry point and cannot be skipped
- confirm that primary credentials create only the documented pre-MFA state
- test enrollment, factor verification, replacement and removal
- verify delivery, expiry, resend, retry and challenge-competition rules
- reject cross-user, cross-session, expired and replayed proofs
- consume successful one-time proof atomically
- verify trusted-device creation, expiry and revocation
- test recovery and lost-device paths as authentication flows
- ensure step-up success elevates only the intended action, tenant or session
Use the MFA and 2FA Test Cases guide for the complete challenge lifecycle and factor-specific cases.
Test Session Creation and Maintenance
Successful authentication normally creates a session. That session becomes part of the authentication contract because it carries identity and assurance across later requests.
- compare pre-authentication and authenticated session identifiers
- assert identity, tenant, role and assurance binding
- test idle and absolute timeout as separate timers
- define which user activity resets inactivity and which background traffic does not
- verify renewal and limit the overlap between old and new tokens
- test remember-me without resurrecting an expired privileged session
- verify tabs, browser contexts and devices according to the sharing policy
- test revocation after password change, factor replacement, compromise and administrative action
- require fresh authentication when the previous state is expired or revoked
Use the Session Management Test Cases guide for the full timer, renewal, browser-context, device and revocation matrix.
Test Logout and Session Termination
Logout is a server-side state transition, not a navigation event. A redirect to the login page is insufficient when the old token, another tab or a background connection still works.
- verify explicit logout from every supported location and device state
- assert server-side invalidation of the intended session
- replay the old cookie or token against representative protected APIs
- test Back, refresh, restored tabs, browser history and cached content
- verify propagation to shared tabs and the documented effect on other devices
- test logout during pending forms, uploads and long-running requests
- separate local application logout from identity-provider logout
- verify remember-me and refresh-token behaviour after termination
- confirm that fresh authentication creates a new session while the old one remains invalid
Test Recovery and Alternative Authentication Paths
Supplementary authentication functions are often weaker than the primary login because they are implemented by different teams, providers or channels.
| Flow | Primary risks to test |
|---|---|
| Password reset | Unknown-user disclosure, wrong reset host, token expiry, replay, account binding, old-password rejection and session policy |
| Account recovery | Weak identity proof, support bypass, factor replacement, audit and user notification |
| Email verification | Wrong account activation, token reuse, tenant assignment and activation before verification |
| Change password | Old credential validity, recent-authentication requirement and session revocation |
| Change email or phone | Reauthentication, confirmation of old/new destination, challenge binding and recovery impact |
| SSO fallback | Local-password bypass, account linking, issuer/tenant mapping and downgrade to a weaker method |
| API authentication | Equivalent policy, token audience, expiry, scopes and error behaviour |
| Support-assisted reset | Operator authority, approval, audit evidence and affected sessions |
Weakest-path rule. The effective strength of authentication is determined by the easiest path that can create or recover the protected state, not by the strongest path displayed on the main login screen.
What Each Testing Layer Can Prove
| Layer | What it can prove | What it cannot prove alone |
|---|---|---|
| Browser journey | Visible prompts, redirects, focus, errors, tabs, storage and final identity | Server-side enforcement across every protected API |
| Authentication API | Credential decisions, challenge creation, attempt policy and structured failures | Complete browser state and accessibility |
| Identity / account store | Account state, identity mapping, factor records and recovery changes | That the user reached the correct visible destination |
| Factor provider | SMS, email, push or authenticator integration events | That the correct application session was elevated |
| Session store | Creation, binding, assurance, renewal, expiry and revocation | That cached browser content was handled safely |
| Protected-resource test | Whether the resulting state can access a representative resource | Why the state was created incorrectly |
| Federation protocol test | Issuer, audience, assertion, nonce/state, account linking and RP session | Local fallback and every post-login workflow |
| Security review | Enumeration, brute force, bypass, replay, fixation and recovery weaknesses | Everyday functional reliability and accessibility |
| Accessibility evaluation | Labels, focus, error association, timer announcement and keyboard completion | Backend identity, session and factor correctness |
Evidence rule. A browser screenshot can prove what the user saw. It cannot by itself prove which server-side session was created, whether an old token remains valid or whether another entry point can bypass the same control.
Build a Risk-Based Authentication Test Matrix
Prioritise by the damage caused by a wrong authenticated state, not by the visual complexity of the screen.
| Priority | Test first | Reason |
|---|---|---|
| Critical | Wrong-user, wrong-tenant, administrative identity, bypass and cross-account factor binding | Creates direct account takeover or tenant isolation failure |
| High | MFA bypass, recovery weakness, session fixation, replay, revocation and sensitive-action step-up | Defeats intended assurance or preserves unauthorised access |
| Medium | Lockout, rate limiting, timeout boundaries, remember-me, concurrent contexts and provider failure | Affects attack resistance and session reliability |
| Normal | Copy, layout, minor navigation and non-blocking presentation differences | Important for usability but lower direct identity risk |
A compact planning matrix can use these dimensions:
entry pointx account statex authenticator or factorx browser / device contextx assurance requirementx expected session transitionx protected resourcex evidence layer
Do not generate the full Cartesian product blindly. Select combinations that change the expected transition, expose a different trust boundary or represent a high-impact failure.
Automate Authentication Without Hiding Defects
Authentication automation needs two complementary paths: real journey tests and prepared authenticated state.
| Strategy | Use it for | Boundary |
|---|---|---|
| Real browser authentication | Login, MFA, redirect, session creation and user-visible failure cases | Slower but required to prove the real transition |
| Authentication API setup | Creating a valid state efficiently when the API itself is trusted and separately tested | Does not prove the browser login flow |
| Prepared Playwright storage state | Unrelated authenticated tests that start after authentication | Can hide broken login, MFA, expiry or revocation |
| Seeded accounts and factors | Deterministic account-state, tenant, role and MFA datasets | Fixtures must reflect production rules and remain isolated |
| Provider sandbox or test authenticator | Stable email, SMS, push and TOTP integration tests | Does not prove the real production provider |
| Manual or device-assisted checkpoint | Hardware, biometric or out-of-band paths that cannot be safely simulated | Not fully unattended |
Recommended suite split:
Small real-journey suite- primary login- MFA- session creation- timeout / revocation- logoutLarger authenticated-feature suite- prepared state- unique accounts per worker- no repeated login unless the feature depends on authentication freshness
Playwright can save cookies, local storage and IndexedDB-backed authenticated state. Treat the state file as a credential, keep it out of version control and refresh it when the session expires.
playwright/.auth/ admin.json member.json mfa-complete.jsonDo not commit these files.Do not use one shared mutable account across parallel workers.Do not claim that prepared state proves authentication.
Automation acceptance rule. Optimisation may skip authentication only in tests whose subject begins after authentication. The dedicated authentication suite must still execute the real transitions it claims to verify.
The Most Important Authentication Failure Patterns
Valid credentials create the wrong identity
The UI may display a generic success state while the backend session maps to another account, tenant or cached user. Assert the final identity in the browser and representative protected APIs.
The browser and backend disagree about authentication
A client may show authenticated navigation before the server accepts the session, or show logged out while an old token still works. Compare browser, API and session-store state.
An alternative entry point is weaker
SSO fallback, mobile, recovery, support tools or an API can create the same protected state with fewer checks. Build one entry-point inventory and compare outputs.
MFA elevates the wrong transaction
A valid proof may be accepted for another user, browser session, tenant or sensitive action. Capture challenge ownership and assert the exact state that was elevated.
The session outlives the authentication policy
Remember-me, silent refresh, background traffic or token overlap can preserve access after timeout, password change, factor replacement or revocation.
Logout changes the page but not the session
A redirect or cleared cookie does not prove server invalidation. Replay the old token and test other tabs, devices and background channels.
Prepared authentication state hides a broken journey
A large suite can remain green while the real login or MFA path is broken because every test starts with stored authentication. Keep a small independent journey suite as a release gate.
Authentication Testing Checklist
- the complete inventory of authentication entry points is documented
- each entry point resolves to the intended identity and tenant
- authentication and authorization assertions are reported separately
- valid credentials create or rotate a fresh session according to policy
- invalid credentials do not create a protected or reusable partial state
- unknown and known identities do not leak unnecessary differences
- rate limiting, lockout and recovery behaviour are deterministic
- account states such as locked, suspended, unverified and deleted are covered
- MFA is required at every intended entry point and cannot be skipped
- factor proofs are bound to the intended user, challenge, session and action
- expired, replayed and cross-user proofs remain outside the protected state
- successful one-time proof is consumed according to policy
- session identity, tenant, role and assurance level are asserted
- idle, absolute, renewal and remember-me policies are tested separately
- background traffic cannot silently simulate user activity
- password change, recovery, factor replacement and compromise events apply the intended revocation policy
- logout invalidates the server-side session rather than only changing the page
- old tokens fail against representative protected APIs after expiry or logout
- Back, restored tabs, cache and other devices follow the termination policy
- recovery and alternative channels are not weaker than the primary path
- federated and local sessions are distinguished
- browser, API, provider, identity-store and session-store evidence are assigned correctly
- prepared authenticated state is used only outside the dedicated authentication journey suite
- authentication state files are treated as credentials and excluded from source control
- high-impact identity, tenant, bypass and revocation scenarios run as release gates
Final acceptance criterion. Do not accept: “The user entered credentials and saw the dashboard.” Accept: “The intended authenticators produced the intended identity and assurance state, only the intended session gained protected access, weaker paths could not bypass the policy, and expired or terminated state remained unusable.”
Frequently Asked Questions
What is authentication testing?
Authentication testing verifies that an application accepts only the intended identity and authenticators, creates the correct session and assurance state, rejects bypassed or invalid paths, and terminates access according to policy.
What is the difference between authentication and authorization testing?
Authentication testing proves who the system accepts and at what assurance level. Authorization testing proves what that authenticated identity may access or change.
Which authentication flows should be tested?
Test every path that can create, recover, elevate, preserve or terminate authenticated access: login, SSO, MFA, magic links, passkeys, recovery, password changes, remember me, sessions, reauthentication and logout.
Can authentication testing be automated?
Yes. Browser tests, authentication APIs, provider sandboxes, seeded factors and session assertions can automate most paths. Some hardware, biometric or external-device scenarios still need device-assisted or manual checkpoints.
Should every automated test perform login?
No. Keep a dedicated real authentication suite, then reuse prepared authenticated state for unrelated tests. Repeating login in every test adds time and instability without adding new authentication evidence.
Does a successful redirect prove authentication?
No. Assert the final identity, server-side session and representative protected resources. Redirects and dashboards can be produced by stale browser state or incorrect account mapping.