StableSeguridadauth

Auth — Login, Sessions and Tokens

Turns the OAuth 2.0 security best current practice, OpenID Connect, and the NIST digital identity guidelines into checkable rules for the flow a product actually builds: the login, the callback, the token, the session, the logout, and the reset.

authenticationoauthoidcpkcesessionstokens

Principios

· P1 — Authentication answers *who*, authorization answers *what*. Separate decisions, separate tokens. An ID token is proof of a login event; an access token is a capability. Using an ID token to authorize an API call, or deriving permissions from a client-held identity claim, collapses two decisions that must be able to fail independently.
· P2 — Every credential is a bearer of blast radius until something binds it. A token that works for anyone holding it works for whoever steals it. Binding — audience, issuer, sender, expiry, single use — is what turns a secret into a scoped one.
· P3 — The client is a delivery mechanism, never the decision point. Browser and mobile code can be read, modified, and replayed. A check that only runs there has not run. The authorization server and the resource server each decide for themselves.
· P4 — Identity flows fail at the seams, not in the primitives. The cryptography is rarely what breaks. What breaks is the redirect that wasn't matched exactly, the state that wasn't checked, the session that wasn't regenerated, the token that outlived the logout. Review belongs at the transitions.
· P5 — There is one correct browser flow: authorization code with PKCE. For every client type, public and confidential alike. Implicit and resource-owner-password are not simpler alternatives, they are withdrawn options. A design reaching for either has misread the problem it is solving.

Patrones

· Don't build it. Delegate authentication to an identity provider or the platform already in the stack. Hand-rolled auth is where a team's remaining security budget goes to die. Exception: a genuinely offline or air-gapped product.
· If a screen shows a password field you wrote, ask what it bought you. Social and magic-link logins remove password storage, reset flows, and breach screening from your surface area entirely. Exception: enterprise buyers who require local accounts.
· Pick the shortest token lifetime the UX survives, then rely on refresh. Long access tokens are chosen to avoid building refresh handling, and that is the wrong reason.
· Prefer an HttpOnly cookie over any token the JavaScript can read.
· Where an SPA talks to your own API, put a thin backend in front of the tokens. The browser holds a session cookie; the server holds the tokens. This costs one small service and removes an entire class of finding.

Riesgos

· Ver anti-patrones específicos del dominio en el pack.

Checklist

[ ] Browser/mobile login uses authorization code + PKCE with S256; no implicit.
[ ] redirect_uri matching is exact-string against an allowlist — no wildcard.
[ ] Post-login "return to" targets cannot be an attacker-supplied absolute URL. (AU13)
[ ] state is sent and verified on the callback. (AU8)
[ ] nonce is sent and verified for OIDC logins. (AU9)
[ ] Token signature, iss, aud, and exp are validated by every service acting.

Fuentes

En la bibliografía AKOS

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

Explorar todas las fuentes →