Il problema delle password condivise
Fino ai primi anni 2000 l’integrazione tra applicazioni avveniva spesso chiedendo all’utente username/password del servizio terzo. Il “calendar sync” che chiede la password di Gmail, il tool di backup che chiede l’accesso Dropbox. Pattern inaccettabile per sicurezza (token sharing permanente, nessuna granularità, difficile revoca).
OAuth 1.0 (RFC 5849, aprile 2010) introduce il concetto di token delegato, ma con firma HMAC complessa. OAuth 2.0 ne è la riscrittura semplificata.
Il rilascio
RFC 6749 e RFC 6750 (bearer token) sono pubblicati dall’IETF nell’ottobre 2012. Editor: Dick Hardt (Microsoft). Il lavoro dura dal 2010, con contributi di Google, Facebook, Twitter, Yahoo.
Attori
- Resource Owner — l’utente
- Client — l’applicazione che vuole accedere
- Authorization Server — emette token (es. accounts.google.com)
- Resource Server — API protetta (es. www.googleapis.com)
Flussi (grant types)
- Authorization Code — standard per webapp con backend; user-agent + backend scambio codice per token
- Implicit — per SPA browser-only; deprecato nel 2021 (OAuth 2.1) per security
- Resource Owner Password Credentials — user dà username/password al client; scoraggiato
- Client Credentials — M2M (machine-to-machine), solo client_id + client_secret
- Refresh Token — rinnovo access token senza re-login
- Device Code (RFC 8628, 2019) — device con input limitato (Apple TV, smart TV)
Token
Gli access token sono opaqui (riferimento) o JWT firmati/crittografati. Bearer token nell’header HTTP:
GET /api/me HTTP/1.1
Authorization: Bearer eyJhbGc...Scope e consent
- Scope — granularità di permessi (
read:profile,write:posts) - Consent screen — utente approva permessi esplicitamente
OpenID Connect
OpenID Connect (OIDC) (febbraio 2014) è layer di autenticazione su OAuth 2.0, aggiunge id_token (JWT con claims utente standardizzati), scope openid, profile, email, UserInfo endpoint. Risolve la confusione tra OAuth (autorizzazione) e identità (autenticazione).
Evoluzione
- OAuth 2.1 (draft 2020+) — consolida best practice, deprecated implicit/ROPC
- PKCE (RFC 7636, 2015) — obbligatorio per tutti i client pubblici
- Token Binding, DPoP — legatura token al client
- FAPI — profili per finanza aperta
Implementazioni
- Keycloak — OSS identity & access management
- Auth0, Okta, Azure AD — SaaS
- Ory Hydra, Ory Kratos — OSS cloud-native
- Spring Security OAuth, Django OAuth Toolkit, Passport-OAuth2
Nel contesto italiano
OAuth 2.0 è fondamento di:
- SPID — federazione identità digitali italiane (con profili ad-hoc)
- CIE — Carta Identità Elettronica (OIDC-like)
- PagoPA — autenticazione API
- Login with Google/Facebook/Apple — ogni sito B2C
- API B2B — banche, telco, PA aperti tramite OAuth scope-based
- PNRR open data — API standardizzate con OAuth
Riferimenti: RFC 6749 (ottobre 2012). IETF. Dick Hardt editor. Flussi authorization code, client credentials, device code. OpenID Connect (febbraio 2014). PKCE RFC 7636. OAuth 2.1 draft 2020+.