# An Identity Checklist — Authentication & Authorization

Source: https://www.skillbyai.com/en/authentication/x-check

> Review before shipping.

## Questions to ask

Are passwords hashed with Argon2id (or bcrypt for legacy) and checked against breached lists? Do login, sign-up and reset avoid enumeration and rate limit by account and source? Are reset and verification tokens random, hashed, expiring and single use? Are session cookies Secure, HttpOnly, SameSite with the `__Host-` prefix, regenerated at login and bounded by idle and absolute timeouts? Are JWTs verified with an algorithm allow-list, `iss`, `aud` and `exp`, with keys from JWKS? Are long-lived tokens kept out of localStorage? Do OAuth clients use the authorization code flow with PKCE and `state`? Is phishing-resistant MFA available? Is authorization enforced per object, deny by default, with tenant scoping? Are auth events audited without secrets?

## The checklist

Use it in design and code reviews.

```text
[ ] passwords: Argon2id/bcrypt, per-hash salt, breached-password check, no forced rotation
[ ] login/sign-up/reset: generic messages, rate limits per account and per source
[ ] reset & verify tokens: CSPRNG, stored hashed, short expiry, single use, sessions revoked
[ ] cookies: Secure, HttpOnly, SameSite, __Host- prefix; CSRF defence on state changes
[ ] sessions: regenerate at login/privilege change; idle + absolute timeouts; real logout
[ ] JWT: algorithm allow-list, verify iss/aud/exp, JWKS rotation, short-lived access tokens
[ ] refresh tokens: server-side, rotated, reuse detection; never in localStorage
[ ] OAuth/OIDC: auth code + PKCE + state + exact redirect URIs; no implicit/password grants
[ ] MFA: TOTP or passkeys offered; SMS only as fallback; recovery codes; MFA step rate limited
[ ] authorization: per-object checks, deny by default, central policy, tenant from identity
[ ] machine identity: hashed scoped API keys, rotation, short-lived workload credentials
[ ] audit: structured auth events, alerts on anomalies, no secrets in logs
```

## Re-review after every new flow

Each new login method, integration or admin feature adds attack surface. Run the checklist again whenever identity flows change, not only before the first launch.

**Quiz:** Which item belongs on an identity review checklist?

- [ ] Password reset links never expire
- [ ] Refresh tokens are stored in localStorage for convenience
- [x] Session IDs are regenerated at login and privilege changes
- [ ] Login errors reveal whether the email exists

*Answer:* Session IDs are regenerated at login and privilege changes. The other options are classic identity weaknesses.