Autenticazione — Cheat Sheet

Tag: auth, jwt, oauth2, security, session, tokens

Livello: intermedio

TL;DR: Distinzione tra autenticazione e autorizzazione, gestione sessioni stateful vs token stateless (JWT), pattern di sicurezza essenziali e mitigazione vulnerabilita'.

Concetti chiave

Autenticazione (AuthN) verifica l'identita'; Autorizzazione (AuthZ) verifica i permessi di accesso.

Session-based: stateful, id sessione salvato nei cookie, stato mantenuto su server o cache distribuita.

Token-based (JWT): stateless, claims firmati crittograficamente, validazione locale senza query al database.

Anatomia JWT: Header (algoritmo), Payload (claims standard e custom), Signature.

Access Token: breve durata, usato per autorizzare le chiamate API verso le risorse protette.

Refresh Token: lunga durata, memorizzato in modo sicuro, usato esclusivamente per rinnovare gli access token.

OAuth 2.0: framework di delega autorizzativa basato su ruoli (Resource Owner, Client, Authorization Server, Resource Server).

OpenID Connect (OIDC): layer di autenticazione sopra OAuth 2.0 che fornisce l'ID Token standardizzato.

Password Hashing: hashing lento e salato (Argon2id, bcrypt, scrypt), mai funzioni veloci come SHA-256 o MD5.

Multi-Factor Authentication (MFA): combinazione di conoscenza (password), possesso (TOTP/token fisico) e inerenza (biometria).

Domande tipiche e risposte pronte

Q: Qual e' la differenza tra autenticazione a sessione e token JWT?R: La sessione e' stateful con ID salvato su server o Redis; JWT e' stateless, firmato e validabile direttamente dal backend senza lookup centralizzato.

Q: Dove conviene salvare l'access token su un frontend web?R: In memoria applicativa se associato a refresh token in cookie HttpOnly, Secure e SameSite per mitigare sia XSS che CSRF.

Q: Come gestisci la revoca di un token JWT se e' stateless?R: Mantengo access token a vita brevissima e, se serve revoca immediata, uso una blacklist/allowlist temporanea su Redis per token o session ID.

Q: A cosa serve il flusso OAuth 2.0 Authorization Code con PKCE?R: Protegge client pubblici (SPA, mobile) dall'intercettazione dell'authorization code tramite code verifier dinamico senza condividere un client secret.

Insidie e errori comuni

Salvare token sensibili o refresh token in localStorage, esponendoli a furto tramite XSS.

Mancata verifica della firma o accettazione dell'algoritmo none nella validazione del JWT.

Inserire dati sensibili (password, PII) non cifrati nel payload JWT, che e' solo codificato in Base64Url.

Omettere i flag HttpOnly, Secure e SameSite=Strict/Lax sui cookie di autenticazione.

Confondere ID Token (per il client) con Access Token (per le API protette).

Mancanza di rate limiting sugli endpoint di login, registrazione o recupero password.

Snippet e comandiTypeScript

// Esempio tipico di verifica JWT con payload tipizzato in Node.js
import jwt from "jsonwebtoken";

interface AuthPayload extends jwt.JwtPayload {
  userId: string;
  role: string;
}

export function verifyAccessToken(token: string, secret: string): AuthPayload {
  return jwt.verify(token, secret, {
    algorithms: ["HS256"],
  }) as AuthPayload;
}

TypeScript

// Esempio configurazione cookie sicuri per refresh token
res.cookie("refreshToken", token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === "production",
  sameSite: "strict",
  maxAge: 7 * 24 * 60 * 60 * 1000,
  path: "/auth/refresh",
});

Da ripassare

[ ] Flusso completo OAuth 2.0 Authorization Code con estensione PKCE

[ ] Implementazione e rotazione dei Refresh Token

[ ] Differenze architetturali e tradeoff prestazionali tra HMAC simmetrico e RSA/ECDSA asimmetrico per JWT

[x] Differenza tra autenticazione e autorizzazione

[x] Hashing sicuro delle password con algoritmi resistenti a brute force (bcrypt/Argon2)

Riferimenti

RFC 7519 (JSON Web Token)

RFC 6749 (OAuth 2.0 Authorization Framework)

RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients)

OWASP Authentication Cheat Sheet

Jarvis Interviews
Jarvis