Testing authentication flaws: A QA Guide (2026)

TL;DR

Testing authentication flaws starts with a state model for login, recovery, MFA, federation, refresh, and logout. Test illegal transitions, binding, expiry, replay, enumeration, abuse controls, session rotation, and direct protected-resource access using synthetic accounts and bounded attempts.

Key Takeaways

• Model authentication as states and transitions across every primary, recovery, MFA, federation, and termination path.
• Test account enumeration through login, registration, reset, resend, recovery, and support channels.
• Use bounded attempts and synthetic accounts for lockout, rate, and credential-abuse testing.
• Recovery tokens and MFA proofs must be bound to one user, purpose, transaction, client, and limited lifetime.
• Rotate session state after authentication, MFA completion, privilege elevation, and account switching.
• Logout and client redirects are not proof of server-side termination, call protected resources with the old credential.
• Redact passwords, tokens, OTPs, cookies, and personal data from every test and telemetry artifact.

Testing authentication flaws means verifying that every path which establishes, recovers, strengthens, or terminates identity resists bypass, enumeration, automated abuse, token misuse, and session confusion. The goal is not to collect clever payloads. It is to prove that an attacker cannot become another user or keep access after the system says that access ended.

For QA and SDET engineers, authentication is a workflow and a distributed state machine. Login is only one transition. Registration, password reset, multifactor enrollment, remembered devices, single sign-on callbacks, refresh tokens, logout, support tooling, and legacy channels can all create an authenticated session. This guide shows how to test them safely and report evidence that developers can act on.

TL;DR

Use approved test accounts, bounded attempts, synthetic personal data, and a dedicated environment. Never perform credential stuffing or disruptive lockout testing against real users or an unapproved production system.

1. Define Testing Authentication Flaws with a State Machine

Authentication answers, with some confidence, who a caller is. Model it as states and transitions rather than a login form. Useful states include anonymous, identifier submitted, primary credential accepted, MFA pending, authenticated, step-up required, recovery pending, locked or risk challenged, and terminated.

List every transition into or out of an authenticated state:

• Password, passkey, certificate, API credential, or federated login.
• Email or phone verification that also creates a session.
• Password reset and magic-link consumption.
• MFA enrollment, challenge, recovery code, and device remembrance.
• Social or enterprise identity provider callbacks.
• Refresh, token exchange, impersonation, and support-assisted recovery.
• Logout, password change, account disablement, risk response, and timeout.

For each transition, define preconditions, proof required, allowed next state, session effect, audit event, and failure behavior. Then test illegal transitions. An anonymous caller must not jump directly to authenticated by calling the MFA verification endpoint without a valid primary-auth transaction. A recovery token for account A must not be combined with a session or identifier for account B.

This state model prevents a common blind spot: testing each screen independently while missing that parameters or tokens can be replayed across workflows. It also makes business impact clear. The invariant is not endpoint returned 400; it is no unauthorized authenticated state or persistent credential was created.

The OWASP Web Security Testing Guide organizes relevant checks across authentication and session management. Use it as a reference, then adapt the cases to the product's actual identities, channels, and risk.

2. Map the Authentication Attack Surface and Trust Boundaries

Inventory user interfaces, mobile and desktop clients, APIs, identity provider endpoints, gateway policies, legacy hosts, regional deployments, and administrator tools. Authentication weakness often survives in an alternate channel after the main web flow is fixed.

Create a route and action catalog:

Mark where untrusted input crosses a boundary. A reverse proxy might inject authenticated identity headers. An application must not accept those headers directly from the public internet. An OAuth callback crosses from browser to relying party and depends on state bound to the initiating browser. A reset link crosses email infrastructure and must remain bound to one account and one purpose.

Review configuration as well as runtime behavior: allowed redirect URIs, identity provider issuer, token audiences, signing algorithms, session cookie attributes, CORS, trusted proxy networks, account lock policy, password policy, risk rules, and log redaction.

Include non-human identities only where their authentication mechanism is in scope. API keys and client credentials have different lifecycle risks from user passwords. The API security testing with OWASP guide provides a broader API threat model.

Rank paths by consequence. Administrator, billing, candidate data, account recovery, and identity-linking flows deserve stronger failure injection and audit checks than a low-risk preference session.

3. Build Safe Accounts, Oracles, and Test Data

Create synthetic accounts that represent active, unverified, disabled, locked, federated-only, password-plus-MFA, passkey-enabled, and recovery-pending states. Include two normal users in different tenants, one privileged user, and accounts whose identifiers differ only by case or Unicode normalization if the identity policy supports such values.

Never use employee or customer accounts for destructive testing. Lockout, reset, session revocation, and MFA recovery tests can interrupt access. Give every test account an owner, environment, allowed role, reset method, and cleanup policy.

Define authoritative oracles. The browser screen is useful but insufficient. Observe:

• Session or access token issuance through the supported client boundary.
• Protected resource access with the resulting session.
• Account status and security settings through a trusted test interface.
• Email, SMS, or push through a controlled sink.
• Security and audit events with secrets redacted.
• Revocation state and active-session inventory if the product exposes them.

Use canary values to detect leakage. A disposable password, reset token, and synthetic one-time code can be searched in logs and traces after the flow. Rotate or destroy them after the test.

Keep timing tests statistical and controlled. Network noise makes single-request timing assertions meaningless. If investigating account enumeration or verifier timing, gather distributions in the same environment with randomized order, then review the implementation path. Do not turn CI into a brittle performance benchmark.

For automation design and data isolation, API test data management helps prevent authentication tests from sharing mutable account state.

4. Test Account Enumeration and Error Disclosure

Account enumeration occurs when responses reveal whether an email, username, phone number, tenant, or external identity exists. Test login, registration, password reset request, resend verification, magic link, MFA recovery, invite acceptance, and support lookup. Fixing login alone leaves several discovery channels.

Compare existing and nonexistent identifiers across status, body code, message, headers, redirects, response size, secondary effects, and timing. Also compare locked, disabled, unverified, and federated-only accounts. A message such as No password exists because this user signs in with Google is helpful to a legitimate user but highly informative to an outsider. Product teams must make an explicit usability and risk decision.

Uniform public responses are a common mitigation. For reset requests, the system can state that instructions will be sent if the account is eligible. That does not mean internal behavior must be identical. It should avoid observable differences that make bulk discovery easy.

Timing needs careful interpretation. Password hashing can make an existing-account path slower than a missing-account path. Servers can perform equivalent verifier work using a fixed dummy hash, but QA should confirm the intended design and measure across many controlled samples. Do not demand exact response equality at the millisecond level.

Check indirect signals: a rate-limit bucket keyed only to existing accounts, different CAPTCHA behavior, a resend countdown, a redirect to an account-specific tenant, or an email provider callback visible to the caller. Registration may need to say an address is already used. If so, consider authenticated reauthentication or secure account-linking paths rather than leaking identity detail to anyone.

Errors must not expose password policy internals unnecessarily, stack traces, SQL messages, signing keys, token content, or identity provider configuration. Stable public codes and a correlation ID support troubleshooting without exposing secrets.

5. Test Password Verification and Automated Abuse Controls

Cover valid password, wrong password, empty, whitespace, extremely long input within safe test limits, malformed encodings, old password after change, temporary password, expired password if supported, and password for another account. Assert no authenticated state is created on failure and that existing valid sessions follow the documented password-change policy.

Password length tests should respect denial-of-service safety. Hashing an enormous attacker-controlled value can consume resources. Test the documented maximum and a modest value above it in QA, then use component tests for larger parser boundaries. Do not send unbounded payloads.

Automated abuse protection can combine per-account, per-network, per-device, and global signals. Test just below, at, and above a small configurable QA threshold. Verify correct credentials after failures according to policy, cooldown, challenge, unlock, and audit behavior. Permanent account lockout can become a denial-of-service tool, so the control should balance abuse resistance and recovery.

Check common bypass dimensions without creating real attack volume:

• Alternate login API or legacy hostname.
• Header or source-address spoofing at the public edge.
• Username case and encoding variations.
• Distributed requests across two controlled clients.
• Password reset or magic link as an easier parallel path.
• Changing only an ignored query parameter to evade cache or counters.

Credential stuffing uses previously compromised username and password pairs. Do not use real breach data. Model the behavior with synthetic accounts and known test passwords, a tiny bounded set, and approved monitoring. Validate rate controls, anomaly signals, MFA or step-up, user notification, and incident evidence.

Review API rate limiting testing for deterministic boundary and recovery techniques.

6. Create Runnable Authentication Negative Tests in Node.js

The following example uses Node.js built-in APIs and a dedicated QA identity endpoint. It limits itself to a small number of attempts, refuses unknown hosts, and never logs passwords or tokens. Adapt error codes and routes to the product contract.

import test from 'node:test';
import assert from 'node:assert/strict';

const baseUrl = new URL(process.env.AUTH_BASE_URL ?? '');
const knownEmail = process.env.QA_AUTH_EMAIL;
const knownPassword = process.env.QA_AUTH_PASSWORD;
const allowedHosts = new Set(['localhost', '127.0.0.1', 'identity.qa.example.test']);

assert.ok(allowedHosts.has(baseUrl.hostname), `Unapproved host: ${baseUrl.hostname}`);
assert.ok(knownEmail, 'QA_AUTH_EMAIL is required');
assert.ok(knownPassword, 'QA_AUTH_PASSWORD is required');

async function post(path, body) {
  const response = await fetch(new URL(path, baseUrl), {
    method: 'POST',
    headers: {
      'content-type': 'application/json',
      accept: 'application/json',
    },
    body: JSON.stringify(body),
    redirect: 'manual',
    signal: AbortSignal.timeout(8_000),
  });

  const text = await response.text();
  return { response, payload: text ? JSON.parse(text) : null };
}

test('known and unknown accounts receive the same public login failure', async () => {
  const known = await post('/v1/login', {
    email: knownEmail,
    password: `wrong-${crypto.randomUUID()}`,
  });
  const unknown = await post('/v1/login', {
    email: `missing-${crypto.randomUUID()}@example.test`,
    password: `wrong-${crypto.randomUUID()}`,
  });

  assert.equal(known.response.status, 401);
  assert.equal(unknown.response.status, 401);
  assert.equal(known.payload.code, 'INVALID_CREDENTIALS');
  assert.equal(unknown.payload.code, 'INVALID_CREDENTIALS');
  assert.deepEqual(Object.keys(known.payload).sort(), Object.keys(unknown.payload).sort());
  assert.equal(Object.hasOwn(known.payload, 'accountId'), false);
});

test('invalid credentials never return a token or session cookie', async () => {
  const { response, payload } = await post('/v1/login', {
    email: knownEmail,
    password: `wrong-${crypto.randomUUID()}`,
  });

  assert.equal(response.status, 401);
  assert.equal(response.headers.has('set-cookie'), false);
  assert.equal(Object.hasOwn(payload, 'accessToken'), false);
  assert.equal(Object.hasOwn(payload, 'refreshToken'), false);
});

test('correct password enters MFA pending, not fully authenticated', async () => {
  const { response, payload } = await post('/v1/login', {
    email: knownEmail,
    password: knownPassword,
  });

  assert.equal(response.status, 202);
  assert.equal(payload.state, 'MFA_REQUIRED');
  assert.equal(typeof payload.transactionId, 'string');
  assert.equal(Object.hasOwn(payload, 'accessToken'), false);
});

AUTH_BASE_URL=https://identity.qa.example.test \
QA_AUTH_EMAIL=mfa-user@example.test \
QA_AUTH_PASSWORD=secret-from-ci \
node --test authentication-flaws.test.mjs

Do not add an automated brute-force loop to a general CI suite. Rate and lockout cases should use a dedicated account, a configurable low threshold, and an explicit security test job.

7. Test Password Reset, Magic Links, and Recovery

Recovery is authentication. It often replaces the primary credential and can be weaker than login if tokens are predictable, long-lived, reusable, loosely bound, or exposed. Model request, delivery, token validation, credential change, and post-reset session policy.

Request reset for existing, missing, disabled, unverified, federated-only, and rate-limited accounts. Compare public responses for enumeration. Inspect the controlled email sink and verify only eligible accounts receive a message, with no password or unnecessary personal data. Links must use the approved HTTPS origin and must not be built from an untrusted Host or forwarded header.

Token cases include valid, malformed, expired, already used, superseded by a newer request, wrong purpose, wrong account context, truncated, modified, and replayed concurrently. The token must be bound to one account and one action. A verification token must not work as a password reset token simply because both have similar format.

After a successful reset, prove one-time use, verify the new credential, and test the old credential. Decide whether existing sessions and refresh tokens are revoked, retained, or shown to the user for review. High-risk applications commonly terminate other sessions, but the expected policy must be explicit.

Magic links need browser and cross-device scenarios. Test whether opening the link on another device is allowed, whether a prefetcher can consume it, whether the link leaks through redirects or referrers, and whether the final session belongs to the correct account. Avoid putting long-lived bearer credentials in URLs.

Support-assisted recovery needs strong staff authorization, reason capture, approval where required, user notification, and immutable audit. Test that support cannot silently disable MFA or change identity for privileged accounts outside policy.

8. Test MFA, Step-Up, and Factor Lifecycle Flaws

MFA testing starts before the challenge. Verify primary authentication creates a limited, short-lived transaction rather than a fully privileged session. Call protected APIs with the pre-MFA cookie or token and expect denial. Try the MFA endpoint without a transaction, with another user's transaction, after expiration, and after successful use.

For time-based one-time passwords, test the documented clock window, current code, adjacent step if allowed, expired code, reused code, malformed code, and bounded repeated failures. Do not hard-code a permanent seed in source. Provision a disposable QA factor through a secure fixture and remove it afterward.

For push or out-of-band approval, bind the prompt to transaction, user, device, and context. Approving an older request must not approve the newest login. Test simultaneous prompts, denial, timeout, repeated notifications, and number-matching if used. A user-friendly fallback must not downgrade security silently.

Factor lifecycle cases include enrollment, confirmation, replacement, removal, recovery codes, trusted devices, and lost-device recovery. Require recent authentication or step-up for sensitive changes. Test CSRF protection for browser flows, authorization for APIs, and notification to the account owner.

Recovery codes should be single-use, high entropy, securely displayed and stored, and invalidated when regenerated according to policy. Use one code twice and confirm the second use fails. Regenerate, then verify old unused codes follow the documented invalidation rule.

Remembered-device behavior needs expiration, device binding, revocation, cookie protection, and risk changes. Copying the remembrance token into another client should not bypass policy if device binding is claimed. Test password reset, MFA reset, and account compromise actions against remembered devices.

Step-up should protect the actual sensitive action, not merely a screen. Capture the action request, remove or alter the step-up proof, change the target after approval, and replay it later. The proof must be bound to user, purpose, and a limited time.

9. Test Session Fixation, Cookies, and Identity Transitions

Session fixation occurs when an attacker can choose or learn a pre-authentication session identifier that remains valid after the victim authenticates. Record the anonymous session, authenticate, and verify the identifier changes. Then attempt to use the old identifier and expect anonymous behavior. OWASP's session fixation guidance explicitly recommends invalidating the old session and issuing a new one after successful authentication.

Repeat rotation checks after privilege elevation, MFA completion, account switching, impersonation start and stop, and sensitive recovery. A session established for user A must never become user B simply because an account identifier in storage or a request changed.

For cookies, inspect Secure, HttpOnly, and an appropriate SameSite value, plus narrow Domain and Path. These flags mitigate different risks and do not replace server-side authorization. Confirm sensitive state-changing requests have CSRF defenses where browser cookies are ambient credentials.

Test duplicate cookies with the same name and different paths or domains in a controlled browser setup. Proxy and framework parsing differences can cause one layer to authorize a different value from another. Clear all relevant variants on logout.

Concurrent sessions need documented behavior. Test whether a new login invalidates old sessions, whether the user can view and revoke devices, and how password or MFA changes affect them. Verify session metadata does not expose full tokens or excessive device information.

Session timeout tests should use an injected clock or short QA settings. Cover idle timeout, absolute lifetime, activity near the boundary, background refresh, browser close if relevant, and server restart. Client-side redirection to login is not termination if the old cookie still accesses the API.

10. Test Tokens, Federation, and Alternative Channels

If the application accepts JSON Web Tokens, validate behavior around signature, issuer, audience, expiration, not-before, subject, token type, and authorization claims according to the product's profile. Decoding a token is not validating it. Do not create arbitrary modified tokens against production. Use controlled test signing keys or component tests for cryptographic negative cases.

Reject an unsigned token when signatures are required, a token signed by an untrusted issuer, a token for another audience, an expired token, and a token whose algorithm or key does not match policy. Verify key rotation and unknown key identifiers fail safely without uncontrolled fetch behavior. Error messages must not reveal verifier configuration.

Federated login requires state and redirect binding. Test missing, wrong, reused, and cross-browser state; authorization responses for the wrong client; unregistered redirect targets; user denial; provider error; duplicate callback; and account-linking conflicts. If OpenID Connect is used, validate nonce and issuer according to the implementation's flow. Do not treat OAuth alone as proof of user authentication.

Account linking is high risk. An attacker should not attach their identity provider account to a victim's existing local account merely by matching an unverified email. Test verified-email rules, recent authentication, conflict resolution, unlinking, and last-login-method protection.

Alternative channels must enforce equivalent policy. Test mobile API, legacy web page, command-line flow, GraphQL mutation, customer support console, regional hostname, and older API version. MFA and lockout enforced on the main UI can be bypassed if an old password endpoint still issues a full session.

The JWT authentication testing guide provides focused token cases that complement full workflow testing.

11. Verify Logout, Revocation, Password Change, and Inactivity

Logout has a user-visible client action and a server-side security effect. Capture the session, log out, then call several sensitive endpoints directly with the old credential. Expect denial according to policy. Browser redirection or clearing local storage alone is not enough.

Test current-session logout, all-sessions logout, device-specific revocation, identity-provider logout if supported, and administrative account disablement. Distributed caches and gateways must receive revocation within the documented objective. Call through multiple nodes or regions where possible.

Bearer access tokens may remain valid until short expiration if the architecture does not introspect them. Refresh tokens, server sessions, or token families can still be revoked. QA should state what is and is not promised, then test the actual boundary. Do not report a non-revocable self-contained access token as a defect if short residual lifetime is the approved design, but do verify sensitive policy expectations.

Password change and reset can have different revocation rules. Test both. Also test email change, MFA reset, role removal, tenant removal, employee termination, and suspected compromise. Authorization data cached inside a session must not preserve removed privilege beyond policy.

Idle and absolute timeout need server proof. Send activity just before idle expiration, remain inactive past it, and check absolute lifetime despite continued activity. Refresh must not extend an absolute cap accidentally. Use controlled clocks rather than long sleeps.

Audit events should identify actor, target, action, result, time, client context, and correlation without storing credentials, reset tokens, OTPs, or full session identifiers. Confirm denied and successful security transitions are distinguishable.

12. Operationalize Testing Authentication Flaws Safely

Split coverage by layer. Unit tests cover state transitions, token validation policies, risk decisions, and recovery token purpose binding. Component tests cover password verifier behavior, session rotation, revocation stores, notification templates, and audit events. Deployed API tests cover gateway routing, cookies, alternate channels, tenant boundaries, and end-to-end termination.

Run deterministic login, recovery, MFA, and session cases on pull requests. Run lockout, rate, key rotation, identity provider failure, telemetry leakage, and distributed revocation in controlled scheduled jobs. Browser tests are important for cookies, redirects, storage, and federated flows, while direct API tests expose skipped screens and illegal transitions.

Protect the suite itself. Secrets belong in the CI secret store. Test accounts use synthetic data and minimal privilege. Target hosts are allowlisted. Reports redact passwords, tokens, cookies, OTPs, and personal data. Untrusted branches do not receive shared credentials.

Classify failures precisely: authentication bypass, account enumeration, authorization failure, session fixation, revocation lag, recovery weakness, MFA bypass, secret exposure, environment failure, or test defect. Include precondition, state transition, request sequence, safe identifiers, correlation IDs, expected authenticated state, actual access, and cleanup status.

Coordinate any abusive or disruptive scenario with security and operations. Define maximum attempts, duration, affected accounts, expected alerts, and a stop condition. Testing authentication flaws should improve assurance without creating an incident.

Review the matrix whenever a new identity provider, client platform, recovery option, proxy, API version, or support workflow is introduced. Authentication coverage decays when the route inventory changes silently.

Interview Questions and Answers

Q: How do you approach testing authentication flaws?

I model authentication as states and transitions across login, MFA, recovery, federation, refresh, and logout. For each transition I test required proof, binding, expiry, replay, and resulting session state. I also verify no protected side effect occurs on failure and inspect safe audit evidence.

Q: How do you test account enumeration?

I compare existing, missing, disabled, locked, and federated-only identities across all discovery-capable flows. I examine status, code, message, headers, redirects, secondary effects, and controlled timing distributions. I avoid brittle single-request timing assertions and focus on material observable differences.

Q: What is session fixation and how would you test it?

Session fixation is reuse of an attacker-known pre-authentication session after a victim logs in. I record the anonymous identifier, authenticate, verify rotation, and try the old identifier against a protected resource. I repeat around MFA and privilege elevation because those transitions also need renewed state.

Q: How do you test MFA bypass?

I try protected APIs with the pre-MFA state, call verification without a valid transaction, swap users or purposes, replay successful challenges, and use alternate login channels. I also test recovery, trusted devices, and factor removal because bypass often occurs around the challenge rather than in OTP validation itself.

Q: What reset-token cases are most important?

I cover wrong account, wrong purpose, expiry, modification, reuse, supersession, concurrent redemption, and host or redirect manipulation. After success I verify the new credential, old credential, token one-time use, session revocation policy, notification, and audit.

Q: How do you test brute-force protection safely?

I use a dedicated synthetic account, a low configurable threshold, bounded attempts, an approved environment, and an explicit stop condition. I test behavior around the boundary, recovery, alternate routes, and alerts. I do not run real credential stuffing or high-volume guesses against users.

Q: What do you validate in an authentication JWT?

I validate signature and allowed algorithm, trusted issuer, intended audience, expiry, not-before, subject, token type, and authorization claims required by the service. I also test signing-key rotation and safe failure. Base64 decoding alone is not validation.

Q: Does logout always invalidate an access token immediately?

Not necessarily. A self-contained short-lived access token may remain usable until expiry while the refresh token or server session is revoked. I clarify the architecture and product promise, then test server-side session termination, refresh denial, and the maximum residual access window.

Q: How do you test federated login?

I verify state, redirect URI, client, issuer, nonce where applicable, callback replay, provider errors, and account linking. I test across browsers and users so artifacts cannot be swapped. I also confirm the resulting local session and authorization map to the correct identity.

Q: What evidence makes an authentication defect actionable?

I provide the exact state sequence, synthetic account type, safe request details, resulting session or access proof, affected route, correlation IDs, revision, and postconditions. I redact all credentials and tokens. I explain the attacker prerequisite and business impact without overstating exploitability.

Common Mistakes

• Testing only the login page and ignoring recovery, MFA, federation, and support paths.
• Treating the UI redirect as proof that server-side access ended.
• Running lockout or credential-guessing tests against real users.
• Comparing one timing sample and declaring an enumeration flaw.
• Logging passwords, reset links, OTPs, cookies, or bearer tokens in reports.
• Validating a JWT by decoding it without checking signature, issuer, and audience.
• Issuing a full session before MFA and relying on the UI to hide protected pages.
• Forgetting to rotate the session after login or privilege elevation.
• Testing token expiry with long sleeps instead of a controlled clock.
• Assuming the newest web flow represents mobile, API, legacy, and regional channels.
• Reporting a status mismatch without proving unauthorized authenticated access or information disclosure.
• Reusing shared accounts whose lock, factor, or session state changes in parallel CI.

Conclusion

Testing authentication flaws is the disciplined search for illegal identity transitions. Map every way the product creates, recovers, strengthens, refreshes, and terminates a session, then test binding, expiry, replay, authorization, side effects, and safe observability at each boundary.

Start with a state diagram and synthetic account catalog. Automate the deterministic transitions, schedule disruptive controls separately, and require direct protected-resource evidence before declaring either authentication success or termination.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Testing session management: A QA Guide (2026)
• API security testing with OWASP: A QA Guide (2026)
• Testing broken access control: A QA Guide (2026)
• Testing for CSRF: A QA Guide (2026)
• Testing for IDOR: A QA Guide (2026)
• Testing for SQL injection: A QA Guide (2026)