Authentication and sessions

Purpose

Authentication answers “who is this?” and sessions carry the answer across requests. Both fail in predictable places: the second login route that skipped the hardening, the reset flow that does not end existing sessions, the MFA prompt that only the web front end enforces. This chapter sets out how those places are found and tested.

Authorisation (what an authenticated identity may do) is covered in chapter 3. In practice the two are tested together, because a token that outlives a role change is both.

Map every entry point first

Before testing any control, the tester lists every way an identity can be established:

• web login, including any separate admin or support login
• mobile and desktop client APIs
• federated sign-in through OAuth 2.0, OIDC or SAML
• API keys, personal access tokens and service credentials
• magic links, invite acceptance and password reset, which are all logins by another name
• legacy, partner or versioned endpoints still reachable from the internet

The list is compared with the scope record. A control is only as strong as the weakest route to the same account, so the comparison is worth doing for every login route (WSTG-ATHN-10 covers this directly).

Login and recovery

Enumeration is checked across every response channel, not only the login error message: sign-up, reset, invite and status codes, plus response timing. Throttling is tested per account and per source address, with rates agreed in the rules of engagement.

Reset and recovery get particular attention because they bypass the password entirely. The checks are mechanical and specific: is the token long and random, is it single use, does it expire, is the link built from a trusted base URL rather than the request’s Host header, and does completing a reset end the sessions and refresh tokens that existed before it? Changing the email address or phone number on an account is treated as a recovery action and should require re-authentication.

Multi-factor authentication

MFA is tested as server-side state, not as a screen. After the first factor, the tester calls post-login endpoints directly to see whether the server considers the session complete. Code entry is checked for attempt limits, replay and binding to the right account. Enrolment and removal are checked for re-authentication, because an attacker with a stolen session who can remove MFA has turned a temporary foothold into a permanent one.

Federated sign-in

For OAuth and OIDC, the tester walks the authorisation code flow and alters each parameter in turn: redirect_uri, state, nonce, the PKCE verifier, and the response type. ID tokens are checked for signature, algorithm, issuer, audience and expiry. Account linking deserves its own test. If the application creates or links an account from an email claim the identity provider has not verified, one tenant’s user can become another’s.

For SAML, the checks focus on which parts of the response the signature covers, replay of a captured assertion, and audience and recipient restrictions.

Sessions and tokens

Session cookies are checked for attributes and scope. Logout and timeout are checked on the server: the tester replays the old session identifier after logout and after the idle period and records whether it still works.

Bearer tokens get the same treatment plus token-specific checks: algorithm handling, key identifiers, expiry, refresh rotation and whether a refresh token can be reused after rotation. Revocation deserves particular attention. A user removed from a tenant, downgraded from admin or forced through a password reset should lose access promptly. When a long-lived JWT or refresh token keeps working, that is recorded with the elapsed time observed.

Synthetic illustration

Synthetic example. All names, hosts and values are fictional. On app.example.com, login with password returns a session marked mfa_pending. The web front end then shows the code prompt. The tester instead calls the account API with the pending session:

GET /api/v1/me/api-keys HTTP/1.1
Host: api.example.com
Cookie: sid=syn_7f3a...e21

HTTP/1.1 200 OK
Content-Type: application/json

{"keys":[{"id":"key_syn_01","prefix":"zk_syn","created":"2026-09-30"}]}

The API checks for a valid session but not for completed MFA. Recorded as ZP-SYN-0102: MFA enforced by the client, not the server (CWE-287, ASVS 5.0 Authentication chapter). The negative control, the same call with no cookie, returns 401.

What evidence looks like

• The entry-point inventory, marked tested, not tested or not reachable, with reasons
• For each finding: account and role used, request and response pairs with secrets redacted, timestamps and build reference
• A negative control showing the expected denial, so the reader can see the control exists elsewhere
• For revocation and timeout issues, the elapsed time between the triggering event and the last successful use of the old credential
• For federated flows, the parameter altered, the value used and the identity provider configuration as observed