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
- 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
Token
Gli access token sono opachi (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
Identity layer
Lavori paralleli nell’IETF e nella OpenID Foundation stanno definendo un layer di autenticazione su OAuth 2.0 — il progetto che diventerà OpenID Connect — per distinguere chiaramente autorizzazione (OAuth) da identità/autenticazione.
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 si candida a diventare il fondamento delle nascenti integrazioni API italiane: ogni banca, telco e progetto di Pubblica Amministrazione che apre API a terzi sta valutando OAuth come schema di autorizzazione.
Riferimenti: RFC 6749 (ottobre 2012). IETF. Dick Hardt editor. Flussi authorization code, client credentials, implicit, ROPC, refresh token.