Authentication, recovery, federation, and session lifecycle

Test registration, recovery, identity changes, invitations, SSO enforcement, and deprovisioning as one account state machine.

Used in these playbooks#

Setup and invariant

Prepare two controlled accounts, separate inboxes, browser profiles, and a recovery route for each. Use an isolated identity provider for federation modifications. Write the accepted identity states: unverified, password accepted, MFA pending, fully authenticated, elevated, recovered, and revoked. The invariant is: each privileged transition requires the right identity proof, and credentials remain bound to their intended account and purpose. Consult documented expiry and revocation semantics before judging residual access. OWASP authentication.

Numbered test procedure

1. Inventory entry points. Record registration, email verification, password login, passkey/MFA completion, mobile login, SSO, API-token issuance, email change, linking, reset, and logout. Capture one complete normal sequence with timestamps and account identifiers. An anonymous call to /api/me and an intentionally invalid credential form negative controls.
2. Check incomplete authentication. Stop A's normal login immediately before MFA. Use that intermediate cookie or token for a single protected profile read. Compare it with a completed A session and an anonymous request. Also check the observed alternate API route; avoid guessing or spraying credentials. Protected access without the required second factor is the finding, not the mere existence of an intermediate token.
3. Check recovery binding. Request one reset for A and one for B. In the local replica, submit A's reset proof with B's account selector, if that selector is client-controlled. After an authorized normal reset of A, replay the consumed proof once. Confirm which controlled account's credential changed by a fresh login. Restore passwords afterward. Single-use, expiry, and account binding are independent checks. OWASP recovery.
4. Check session transitions. Save the pre-login identifier, completed session, and any refresh credential separately. Compare identifiers after login and elevation. Perform logout or explicit device revocation and make one old-session profile request. Record access and refresh outcomes separately; a refresh token being revoked does not necessarily revoke already-issued access tokens. Evaluate the actual advertised security behavior. OWASP sessions.
5. Check identity changes and pre-existing state. Change A's verified email to a second owned inbox; compare verification, pending state, and recovery delivery before/after confirmation. In the replica, keep an unverified password account open, then complete the legitimate verified/federated signup for the same owned inbox in another profile. Inspect whether the original password, session, or linked identity can still access the now-verified account. Independently test reusing a stale verification link after another email change. A duplicate signup error or two aliases reaching the same mailbox proves no takeover. Do not assume case folding, dot removal, or plus-address handling is universal. Email identity comparison and verification.
6. Follow enterprise onboarding and offboarding. Use a disposable tenant with a second recovery administrator. Record invitation recipient/role/tenant, acceptance, cancellation, SSO enforcement, group assignment, and deactivation. Compare a fresh invite with one cancelled invite; confirm whether a changed recipient is allowed by the product contract. After enabling enforced SSO, attempt the observed password, reset/magic-link, and alternate client entry paths once with controlled accounts, then request one protected tenant object. Deliberate break-glass exceptions are separate policy. For SCIM, use the tenant's provisioning credentials and verify deactivation, group removal, token refresh, and existing streams after the configured sync interval. SCIM active has provider-defined semantics; it is not a universal immediate-session-kill instruction. SCIM schema. Provisioning credentials must still map to the permitted tenant/resources. SCIM authorization.
7. Follow the specialized proof branches. Use MFA/passkey lifecycle for enrollment, factor replacement, backup-code reuse, and WebAuthn verifier checks. Use federation/token trust for OAuth PKCE, OIDC claim and account-linking decisions, JWT validation, and SAML. Do not substitute decoded claims for a protected-resource result. Document which providers, authentication methods, and enterprise features were unavailable rather than marking them passed.

Command card

Export A's local cookie jar before using the application's real logout button. These requests compare protected content before and after logout; routes and credential transport must match the replica.

mkdir -p evidence/session
chmod 600 A-before.cookies
curl -q --noproxy '*' --max-time 10 -b A-before.cookies \
  -D evidence/session/before.h -o evidence/session/before.json \
  http://127.0.0.1:8000/api/me
# Perform the actual logout or device-revocation workflow now.
curl -q --noproxy '*' --max-time 10 -b A-before.cookies \
  -D evidence/session/after.h -o evidence/session/after.json \
  http://127.0.0.1:8000/api/me
curl -q --noproxy '*' --max-time 10 -o evidence/session/anonymous.json \
  http://127.0.0.1:8000/api/me

Report threshold and checklist

Report access as the wrong controlled identity, completion without required authentication, unauthorized account linking, or a material violation of revocation guarantees. Cosmetic logout, unsent browser cookies, decoded JWT contents, and reset forms displaying without completing are common false positives.

• Account and session state recorded for every request.
• Browser binding distinguished from token validity.
• Correct and incorrect proofs compared independently.
• Fresh login verifies any credential or linking change.
• Verification, linking, invitations, and enforced-SSO fallback paths evaluated.
• Provisioning changes checked against configured sync and revocation behavior.
• Recovery settings restored; live tokens removed from report.

Vulnerability reverse references#

• Authentication or MFA state bypass — A session that has not completed required authentication can perform protected operations.
• Session fixation across login — A session known to an attacker remains usable after another controlled user authenticates into it.
• Residual access after explicit session revocation — A revoked credential or removed membership retains access beyond the product’s applicable revocation guarantee.
• Password reset binding or single-use failure — Recovery proof can change the wrong account or be reused contrary to the recovery contract.
• OAuth login or account-linking confusion — An authorization response or external identity is bound to the wrong application session or controlled account.
• JWT signature, issuer, audience, or token-purpose validation failure — A service accepts token claims without the required signature or trusted issuer/key validation.
• WebSocket message or subscription authorization failure — A valid connection performs unauthorized per-message actions or receives a private subscription.
• Mobile link handler trusts routing as authorization — An externally supplied custom or universal/app link reaches a protected client operation without validating the route input and current security context.
• Local authentication does not gate the protected operation — A local PIN or biometric screen is bypassed through another reachable path while the supposedly protected data/key operation remains usable.
• Backup or transfer exposes unintended sensitive client state — A supported backup, migration or diagnostic-copy path carries a secret into an unintended recipient or security context.
• MCP proxy consent confuses different clients — A proxy reuses upstream consent in a way that grants a new MCP client access without the resource owner’s intended per-client consent.
• MCP accepts a token for another resource — A protected MCP resource accepts a token that was not issued for that resource.
• Signed action does not bind its intended context — A valid signature is accepted for another recipient, action, verifier or chain context contrary to the authorization contract.
• Open redirect across an origin trust boundary — Attacker input controls a navigation destination that the application treats as trusted.
• Untrusted Host or forwarding-header origin construction — The application constructs a security-sensitive origin from request metadata that an attacker can influence.
• Predictable security token or capability identifier — A security token relies on randomness that does not meet its unpredictability requirement.
• SAML assertion signature, audience, or response binding failure — The service provider trusts an assertion whose signature or authentication context is not valid for the receiving flow.
• Unauthorized authenticator enrollment, replacement, or removal — A lower-assurance or wrong-account context can add, replace, or remove an authentication factor contrary to its management policy.
• WebAuthn assertion accepted for an invalid account or ceremony context — The relying party accepts a passkey assertion without the required account, challenge, signature, origin, or verification binding.
• Verification or account merge preserves another actor's access — Registration, verification, email change, or federation merging transfers trust to an identity while retaining an unintended actor's usable credentials or session.
• Enforced SSO bypass through an alternate login path — A protected tenant requiring federation remains accessible through a local or alternate authentication path outside the documented exceptions.

Nearby shared procedures#

Object, function, and property authorization · Trace input into queries, commands, and templates · Server-side fetching and network trust boundaries · Browser execution, cross-origin reads, and forged actions · Uploads, downloads, paths, archives, and XML · Workflow invariants, replay, idempotency, and races · REST, GraphQL, gRPC, WebSocket, and SSE permission parity · Proxy normalization, cache isolation, and request boundaries