OAuth 2.0 & OpenID Connect: Una Guida Essenziale per Sviluppatori Web

Ogni volta che fai clic su "Accedi con Google" o "Registrati con GitHub", stai sfruttando la potenza di OAuth 2.0. Questo protocollo è diventato lo standard del settore per la gestione dell'autorizzazione. Quando abbinato a OpenID Connect (OIDC), estende le sue capacità anche all'autenticazione. Comprendere a fondo OAuth è fondamentale per ogni sviluppatore web che mira a integrare accessi di terze parti o API nelle proprie applicazioni.

Autenticazione vs Autorizzazione

• Autenticazione (AuthN): "Chi sei tu?" — Il processo di verifica dell'identità. È il compito principale di OpenID Connect.
• Autorizzazione (AuthZ): "Cosa puoi fare?" — La concessione di permessi e accessi a risorse protette. Questo è il fulcro di OAuth 2.0.

OAuth 2.0 è stato progettato primariamente per l'autorizzazione — permettere a un'applicazione di terze parti di accedere, ad esempio, ai tuoi file su Google Drive senza che tu debba fornirle la tua password di Google. OpenID Connect si sovrappone a questo strato, fornendo un metodo standardizzato per ottenere le informazioni sull'identità dell'utente, gestendo l'autenticazione in modo sicuro.

Gli Attori Principali

Per comprendere appieno i flussi di OAuth, è essenziale familiarizzare con i ruoli chiave:

• Proprietario della Risorsa (Resource Owner): L'utente finale che possiede i dati o le risorse protette (cioè, tu).
• Client: L'applicazione (la tua app, un sito web o un'app mobile) che desidera accedere alle risorse protette per conto del Resource Owner.
• Server di Autorizzazione (Authorization Server): Il servizio (es. Google, GitHub, un Identity Provider come Auth0) che autentica il Resource Owner e, in caso di consenso, rilascia i token al Client.
• Server di Risorse (Resource Server): L'API che ospita i dati protetti a cui il Client vuole accedere (es. Google Drive API, GitHub API).

Flusso di Codice di Autorizzazione (con PKCE)

Questo è il flusso più sicuro e raccomandato per applicazioni web tradizionali, single-page applications (SPA) e app mobile. PKCE (Proof Key for Code Exchange) aggiunge un ulteriore strato di sicurezza, prevenendo attacchi di intercettazione del codice di autorizzazione, specialmente in ambienti meno sicuri come i browser.

1. L'utente clicca "Accedi con Google" sulla tua applicazione
2. La tua app reindirizza l'utente all'endpoint di autorizzazione di Google:
   GET https://accounts.google.com/o/oauth2/v2/auth?
     response_type=code
     &client_id=YOUR_CLIENT_ID
     &redirect_uri=https://yourapp.com/callback
     &scope=openid email profile
     &state=random_csrf_token
     &code_challenge=SHA256_HASH
     &code_challenge_method=S256

3. L'utente effettua il login su Google e concede i permessi richiesti
4. Google reindirizza l'utente alla tua app con un codice di autorizzazione:
   GET https://yourapp.com/callback?code=AUTH_CODE&state=random_csrf_token

5. Il tuo server scambia il codice per i token:
   POST https://oauth2.googleapis.com/token
   Body: {
     code: AUTH_CODE,
     client_id: YOUR_CLIENT_ID,
     client_secret: YOUR_CLIENT_SECRET,
     redirect_uri: https://yourapp.com/callback,
     grant_type: authorization_code,
     code_verifier: ORIGINAL_RANDOM_STRING
   }

6. Google restituisce:
   {
     "access_token": "ya29.a0...",
     "id_token": "eyJhbGci...",       // Token di identità OpenID Connect
     "refresh_token": "1//0e...",
     "expires_in": 3600,
     "token_type": "Bearer"
   }

Comprendere i Token

I token sono le credenziali che consentono alla tua applicazione di agire per conto dell'utente.

• Access Token: Di breve durata (tipicamente 1 ora). È la chiave per chiamare le API del Server di Risorse per conto dell'utente. Va incluso nell'header HTTP Authorization: Bearer <token> di ogni richiesta API.
• Refresh Token: Di lunga durata. Utilizzato per ottenere nuovi access token quando quelli attuali scadono, senza richiedere all'utente di autenticarsi nuovamente. Deve essere conservato in modo estremamente sicuro (solo lato server, mai in client-side storage come localStorage o sessionStorage).
• ID Token: Un JWT (JSON Web Token) che contiene informazioni sull'identità dell'utente (email, nome, immagine, ecc.). Questa è l'aggiunta specifica di OpenID Connect a OAuth 2.0, fornendo un meccanismo standard per l'autenticazione.

Scope (Ambiti)

Gli "scope" definiscono quali permessi la tua applicazione sta richiedendo al Resource Owner. Sono presentati all'utente nella schermata di consenso, permettendogli di capire e approvare (o meno) le autorizzazioni prima di procedere.

// Scope specifici per OpenID Connect (OIDC)
openid        // Obbligatorio per OIDC, indica che l'app vuole autenticare l'utente
email         // Richiede accesso all'indirizzo email dell'utente
profile       // Richiede accesso al nome, immagine profilo, locale dell'utente

// Scope specifici per Google
https://www.googleapis.com/auth/drive.readonly // Permesso di leggere file su Google Drive
https://www.googleapis.com/auth/calendar       // Permesso di accedere al calendario

// Scope specifici per GitHub
read:user     // Permesso di leggere il profilo utente
repo          // Accesso completo ai repository
read:org      // Permesso di leggere l'appartenenza alle organizzazioni

Migliori Pratiche di Sicurezza

Implementare OAuth 2.0 e OpenID Connect richiede attenzione alla sicurezza per proteggere sia i dati degli utenti che la tua applicazione.

• Usa sempre PKCE: Anche per le applicazioni lato server. È obbligatorio per i client pubblici (SPA, app mobile) e fortemente consigliato per tutti.
• Valida il parametro state: È cruciale per prevenire attacchi CSRF (Cross-Site Request Forgery) e deve essere confrontato con un valore generato e conservato lato server per ogni richiesta.
• Non archiviare mai i token in localStorage: Utilizza invece cookie HTTP-only, sicuri (Secure) e con attributo SameSite per gli access token e i refresh token. I cookie HTTP-only prevengono l'accesso tramite JavaScript.
• Valida gli ID token: Controlla sempre l'issuer, l'audience, la scadenza e la firma del token JWT per assicurarti che sia valido e non sia stato manomesso.
• Richiedi scope minimi: Chiedi solo i permessi strettamente necessari per il funzionamento della tua applicazione. Meno permessi, minore rischio in caso di compromissione.
• Utilizza access token di breve durata con rotazione dei refresh token: Limita la validità degli access token e implementa una strategia di rotazione per i refresh token per minimizzare l'impatto di un eventuale furto.

Quando Utilizzare Cosa

La scelta del flusso di autorizzazione dipende dal tipo di applicazione che stai sviluppando e dal contesto di sicurezza.

• Authorization Code + PKCE: La scelta predefinita e consigliata per la stragrande maggioranza delle applicazioni: web app tradizionali, Single-Page Applications (SPA) e app mobile. Offre il massimo livello di sicurezza.
• Client Credentials: Ideale per comunicazioni server-to-server, quando non c'è un utente finale coinvolto. Il server autentica se stesso per accedere alle risorse.
• Device Code: Progettato per dispositivi con capacità di input limitate, come Smart TV, dispositivi IoT o applicazioni da riga di comando (CLI).
• ⚠️ Implicit Flow: È ufficialmente deprecato e sconsigliato per nuove applicazioni a causa di vulnerabilità di sicurezza intrinseche. Evitalo a favore del flusso Authorization Code + PKCE.