# Authentication testing checklist: login, reset, MFA, sessions and OAuth

Source: https://penetrationtestservices.com/guides/authentication-testing-checklist/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

An authentication testing checklist for web apps and APIs: login, password reset, MFA, sessions, OAuth and account enumeration, with proof and fixes.

> **Short answer:** An authentication testing checklist covers every way a user proves identity and keeps a session: login, password reset, MFA, session cookies and tokens, OAuth or SSO, and account enumeration. Each item has a test, the evidence that proves a flaw, and a fix. Run it with test accounts you own and within a written scope.

An authentication testing checklist covers each way a user proves identity and keeps a session: login, password reset, MFA, sessions, OAuth and account enumeration. Authentication Failures is A07:2025 in the [OWASP Top 10](/guides/owasp-top-10-2025/). Broken Authentication is API2:2023 in the [API list](/guides/owasp-api-security-top-10/).

Run the checklist only on systems you are authorized to test, and only with test accounts you own. It belongs to the scope of a [web application penetration test](/web-application-penetration-testing/).

## How do testers test login?

Login tests check that a wrong credential fails the same way every time, and that the server limits repeated tries.

- [ ] Wrong password and unknown user return the same message and about the same response time.
- [ ] The app limits repeated failures per account and per source. See [rate limiting and credential stuffing](/guides/rate-limiting-and-credential-stuffing/).
- [ ] Credentials travel only over HTTPS and never appear in URLs or logs.
- [ ] A new session ID is issued at login (no session fixation).
- [ ] Default and shared accounts are absent from production.
- [ ] Every other login route (mobile API, legacy endpoint, SSO callback) applies the same checks.

Evidence: two request and response pairs with timestamps, one for a valid user and one for an unknown user, plus the count of attempts before any lockout.

## How do testers test password reset?

Reset flows are an account takeover path, so testers check the token, how it is delivered and whether it can be reused.

- [ ] The reset token is long, random and single-use.
- [ ] The token expires, and a new request invalidates older tokens.
- [ ] The reset link does not use a `Host` header that the client can change.
- [ ] The response for a known and unknown email is the same.
- [ ] After a reset, old sessions and tokens are revoked.
- [ ] Security questions are absent or not the only check.

> **Illustrative reset-token reuse check:** This is a demonstration. No real customer system was tested. The host is fictional.
> 
> The tester requests a reset for their own test account, uses the link once, then replays it:
> 
> ```http
> POST /api/v1/password/reset HTTP/1.1
> Host: app.harbor-notes.example.com
> Content-Type: application/json
> 
> {"token": "", "new_password": ""}
> ```
> 
> ```http
> HTTP/1.1 400 Bad Request
> Content-Type: application/json
> 
> {"error": "token_used"}
> ```
> 
> The server rejected the second use, so the control held. A `200` would have sent the tester to log in with the new password to show the effect.
## How do testers test MFA?

MFA tests check that the second step is required, limited and tied to the first step.

- [ ] The second step cannot be skipped by calling a later endpoint directly.
- [ ] Codes expire and cannot be reused.
- [ ] The app limits wrong codes per account and per session.
- [ ] A code from one session does not work in another.
- [ ] Recovery codes and "trust this device" cookies are bound to the user and expire.
- [ ] Changing MFA settings needs a recent re-authentication.
- [ ] Other login routes (API, SSO) enforce MFA too.

Evidence: the request sequence showing which step the tester skipped, and the authenticated read-back that shows the session works or does not.

## How do testers test sessions?

Session tests check cookie flags, lifetime and what happens at logout.

| Check | Expected | Flaw if |
|---|---|---|
| `Secure` flag | Set on the session cookie | Cookie sent over HTTP |
| `HttpOnly` flag | Set | Script can read the cookie |
| `SameSite` | `Lax` or `Strict` | Missing or `None` without need |
| Logout | Server ends the session | Old cookie still works |
| Password change | Other sessions end | Old sessions stay valid |
| Idle and absolute timeout | Enforced on the server | Only the browser clears it |
| Cookie value | Random, no user data | Guessable or editable |
| Token (JWT) | Signature, expiry, audience checked | Unsigned or expired token accepted |

A good fix sets the flags in one place:

```http
Set-Cookie: session=; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
```

Evidence for logout: save the cookie, log out, replay the saved cookie against a protected route, and show the response.

## How do testers test OAuth and SSO?

OAuth tests check the redirect and the token exchange.

- [ ] The `redirect_uri` is matched exactly against a registered value.
- [ ] The `state` parameter is random, bound to the session and checked on return.
- [ ] Authorization codes are single-use and short-lived.
- [ ] PKCE is used for public clients.
- [ ] The app checks the ID token's issuer, audience, signature and expiry.
- [ ] Account linking needs a verified email from the provider.
- [ ] Scopes asked for match what the app needs.

An unchecked `state` also opens login CSRF: see the [CSRF testing guide](/guides/csrf-testing/).

## How do testers check for account enumeration?

Enumeration lets a caller learn which accounts exist. Compare the response body, status code, headers and timing for known and unknown users on login, reset, sign-up and invitation routes. A single difference is a finding. Its severity depends on how much the product relies on secrecy of who has an account.

Fix it with one generic message ("If the account exists, we sent an email") and the same work on both paths so timing is alike.

## What does a good finding look like?

A good finding names the route, the test account, the steps, the evidence and the fix. It also lists the controls that held. The tester shows the effect, such as a working session after logout, because a "success" response is not proof.

## How do teams fix authentication flaws?

Use a proven library or identity provider instead of custom code. Set short lifetimes for reset tokens and sessions, and revoke them on logout and password change. Limit attempts per account and per source, and apply the same rules to every login route. Log authentication events and review them. Then retest the fix against the same request pairs.

## In what order should you run the checks?

Start with the checks that change what you can test next. A weak lockout or a bypass in one flow can affect the rest of the test.

1. Map every login route: web form, mobile API, SSO callback, legacy endpoint and admin login.
2. Create test accounts for each role, with and without MFA.
3. Run the response comparison for enumeration on login, reset and sign-up.
4. Test sessions across login, logout and password change.
5. Test reset and MFA with owned accounts.
6. Test OAuth and SSO with a test identity provider tenant, if one exists.
7. Run bounded limit tests last, inside the window the scope allows.

Run limit tests last because they can lock a test account. Create a spare account before you start.

## What does an authentication finding look like?

A finding shows the failed check and the effect. This illustrative write-up shows the parts.

> **Illustrative finding write-up:** This is a demonstration. No real customer system was tested. The app and host are fictional.
> 
> | Field | Detail |
> |---|---|
> | Title | Session stays valid after logout |
> | Label | Observed |
> | Route | `GET /api/v1/me` |
> | Accounts | one test account created for this test |
> | Steps | (1) Sign in and save the session cookie. (2) Call `/api/v1/me`: 200. (3) Sign out in the UI. (4) Replay the saved cookie. |
> | Result | The replayed cookie returns 200 with the test user's profile. |
> | Controls that held | A cookie with a changed last character returns 401. A cookie from before a password change returns 401. |
> | Impact | A stolen cookie works after the user signs out. |
> | Fix | Delete the session on the server at logout, and reject any ID that is not in the session store. |
The changed-cookie control shows that the server does check cookies, so the logout result is a real finding.

## What do testers need from you?

Testers need these items to cover every route.

- Test accounts for each role, with MFA on and off.
- A test inbox or mail catcher for reset and verification mail.
- A list of identity providers and the redirect URLs they use.
- The rules for lockout and session lifetime, if you have them.
- A named contact for lockouts and mail questions.

## Questions

### Should testers try to guess real users' passwords?

No. Password tests use test accounts that the tester owns, with bounded attempts that the scope states. Testing against accounts you do not own is not authorized, even inside an authorized scope.

### Is MFA enough to stop account takeover?

MFA raises the cost of an attack, but flaws remain. Testers check whether the second step can be skipped, guessed without limits, replayed, or bypassed through recovery and other login routes.

### How long should a session last?

It depends on the risk. OWASP guidance sets idle and absolute timeouts by application risk. Agree the values with your team, then test that the server enforces them and that logout ends the session on the server.

### Does the checklist apply to APIs that use tokens?

Yes. Replace cookies with bearer tokens. Check signature validation, expiry, audience, refresh token rotation and revocation after logout or password change.

## Sources

- [OWASP WSTG: Authentication Testing](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/04-Authentication_Testing/)
- [OWASP WSTG: Session Management Testing](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/06-Session_Management_Testing/)
- [OWASP Top 10:2025 Introduction](https://top10.owasp.org/2025/0x00_2025-Introduction)
- [OWASP API Security Top 10 2023](https://api-security.owasp.org/editions/2023/en/0x11-t10)
- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)