---
name: web-auth-session-review
description: Investigate authentication and session trust boundaries: signed claims versus consumed identity, SAML/XML parser differences, email normalization, token audience/issuer/session binding, and client-side session serialization. Use on a concrete login, SSO, recovery or session flow.
---

# Authentication and session specialist

A locally curated native guide grounded in the linked primary research, not an official skill package
from those researchers. Read [research-cases.md](references/research-cases.md) for relevant examples.

## Establish what is trusted

Map the browser/client, relying party, identity provider, verifier, key source, session store and
downstream authorization. Identify exactly what artifact is authenticated and what identity or role
the application later consumes. Record token format, issuer/audience, response correlation, tenant,
signature verification, and intended victim interaction where applicable.

Do not infer server behavior from a decoded token or UI. Verify the actual endpoint needs that token,
and distinguish responses caused by a valid session cookie, a public route, or a previously granted role.

## Follow the selected mismatch

- For signatures or assertions, compare the object/bytes verified with the object/identity consumed.
  Check parser, namespace, canonicalization and duplicate-element behavior in a local reproduction
  tied to the deployed version. A valid signature on one object must not authorize another object.
- For email/domain identity, trace the representation accepted at enrollment, verification, delivery,
  lookup and role assignment. A formatting discrepancy matters only if it changes authority or identity.
- For sessions, distinguish signed from encrypted data, follow key selection and data-only versus
  object deserialization, and identify which attacker-controlled data can reach a sensitive sink.
- For OAuth/OIDC or recovery flows, identify the intended binding of request, client, redirect,
  subject, tenant and session. Test only the specific missing binding supported by observed evidence.

## Discriminate before reporting

Use owned accounts and a protected, synthetic operation as the oracle. Compare the authorized request,
an actually invalid artifact, and the treatment. Verify the authenticated principal and resulting
permission, not just a status code or response length. A non-401 response is not proof of acceptance.
Show how a realistic attacker obtains each artifact without borrowing victim authority.

Do not run blanket token forgery lists or key cracking. If unexpected secrets appear, follow the
global stop-and-report rule. Prefer local replicas or fixtures with keys you own when investigating
signing and serialization behavior. Preserve reproducible prerequisites and apply fp-check.