OAuth Spiegato: Ruoli, Flusso PKCE e OAuth vs SAML
OAuth Spiegato
Cos'è OAuth? Ruoli, Flusso PKCE, OAuth vs SAML vs OIDC | We.Inc
OAuth 2.0 in parole semplici: quattro ruoli, il flusso authorization code con PKCE passo per passo, gli scope e in cosa OAuth differisce da OpenID Connect e SAML.
OAuth 2.0 è uno standard che permette a un'app di agire per tuo conto su un altro servizio senza mai vedere la tua password. Approvi una richiesta sulla pagina di accesso del servizio stesso, e l'app riceve un access token limitato agli scope che hai accettato. Si occupa dell'autorizzazione; OpenID Connect aggiunge l'accesso sopra di esso.
OAuth 2.0 vs OpenID Connect vs SAML 2.0
OAuth 2.0
OpenID Connect
SAML 2.0
Risponde a
A cosa può accedere questa app?
Chi è questo utente?
Chi è questo utente?
Elemento principale
Access token
ID token (un JWT) più access token
Asserzione XML
Specifica
RFC 6749 (IETF)
OpenID Connect Core 1.0
OASIS SAML 2.0
Parti coinvolte
Client, authorization server, resource server
Relying party, OpenID provider
Service provider, identity provider
Uso tipico
Accesso alle API, "collega il tuo account"
Pulsanti "Accedi con", login su mobile e SPA
Single sign-on aziendale
Prima di OAuth, collegare due servizi significava spesso digitare la password di uno dentro l'altro. OAuth l'ha sostituito con token a breve durata e con permessi limitati, emessi solo dopo la tua approvazione. Il generatore qui sotto crea nel tuo browser un vero verifier e challenge PKCE e costruisce l'URL di autorizzazione, così puoi vedere ogni parametro usato dal flusso.
L'app crea un code_verifier casuale, ne calcola l'hash per ottenere un code_challenge e ti manda all'authorization server con quel challenge, il suo client_id, gli scope e un valore state.
Accedi sulla pagina dell'authorization server e approvi gli scope.
Il server reindirizza al redirect_uri dell'app con un authorization code a breve durata e lo stesso state.
L'app controlla state, poi invia il code e il code_verifier originale al token endpoint.
Il server calcola l'hash del verifier, lo confronta con il challenge salvato e restituisce un access token che l'app invia all'API.
Usa il flusso authorization code con PKCE sia per le single page app, sia per le app mobile, sia per le app lato server.
Invia e controlla sempre state, che la specifica OAuth raccomanda per prevenire il cross-site request forgery.
Chiedi gli scope più ristretti che bastano allo scopo; le persone approvano più volentieri le richieste piccole.
Registra redirect URI esatti. Wildcard e open redirect sono un modo classico in cui i token vengono rubati.
Tieni i client secret solo sul server. Un'app nel browser o mobile non può custodire un segreto.
Domande frequenti
OAuth è autenticazione o autorizzazione?
Autorizzazione. Un access token dice cosa può fare un'app, non chi è l'utente, e le API potrebbero non dirtelo nemmeno. Quando ti serve l'identità della persona, usa OpenID Connect, che restituisce un ID token firmato con claim come sub, iss, aud ed exp.
Cos'è PKCE e mi serve?
PKCE (RFC 7636) lega l'authorization code all'app che ha avviato il flusso. L'app invia prima l'hash di un segreto casuale e solo dopo il segreto stesso, così un code rubato è inutile. Usa S256, che i server devono supportare, invece di plain.
Qual è la differenza tra OAuth e SAML?
SAML è uno standard più vecchio basato su XML, in cui un identity provider invia un'asserzione firmata sull'utente a un service provider, soprattutto per il single sign-on aziendale nel browser. OAuth emette token per l'accesso alle API e funziona bene per app mobile e API. OpenID Connect è l'equivalente più vicino, nel mondo OAuth, dell'accesso con SAML.
Cosa sono gli scope?
Gli scope sono i permessi che un'app richiede, scritti come una lista separata da spazi di stringhe sensibili alle maiuscole definite dall'authorization server, per esempio openid email oppure repo read:user. La schermata di consenso li mostra, e il token copre solo ciò che è stato approvato.
Devo ancora usare il flusso implicit?
No per i nuovi progetti. Restituiva i token nel frammento dell'URL, dove possono trapelare tramite cronologia e log. Il flusso authorization code con PKCE dà alle app nel browser la stessa comodità senza quell'esposizione.
I quattro ruoli
L'RFC 6749 definisce quattro parti. Il resource owner sei tu. Il client è l'app che chiede l'accesso. L'authorization server verifica chi sei ed emette i token. Il resource server ospita l'API che accetta quei token. Spesso un'unica azienda gestisce entrambi i server, ma sono compiti distinti.
Perché esiste lo scambio del code
Il reindirizzamento verso l'app passa attraverso il browser, un posto poco sicuro per qualsiasi cosa di valore. Per questo il reindirizzamento trasporta solo un code monouso, che la specifica raccomanda di far scadere entro 10 minuti. Il vero token si ottiene con una chiamata diretta al token endpoint.
PKCE chiude la falla rimanente. Anche se un malware o un proxy che registra il traffico cattura il code, non può riscattarlo senza il verifier, che non ha mai lasciato l'app.
Dove si inserisce OpenID Connect
OpenID Connect è un sottile livello sopra OAuth. Aggiungi openid agli scope, cosa che la specifica OIDC rende obbligatoria, e la risposta del token contiene anche un ID token: un JWT firmato che descrive l'utente. Un nonce inviato nella richiesta e ripetuto nell'ID token protegge dagli attacchi replay.
Il flusso authorization code con PKCE
Ogni passaggio e i parametri che trasporta
Passaggio
Da, a
Parametri chiave
1. Richiesta di autorizzazione
Dall'app all'authorization server (redirect del browser)
access_token, token_type, expires_in, refresh_token facoltativo (e id_token con OIDC)
6. Chiamata API
Dall'app al resource server
Authorization: Bearer <access_token>
PKCE nel codice
Creare un verifier e un challenge S256 nel browser
32 byte casuali codificati in base64url danno un verifier di 43 caratteri, la lunghezza minima consentita dall'RFC 7636.
Scambiare il code con i token
Si esegue dopo il reindirizzamento. Confronta prima state, poi invia il verifier salvato insieme al code.
Generatore PKCE e URL di autorizzazione
Crea un nuovo code_verifier e il relativo code_challenge S256 con le funzioni crittografiche del tuo browser, poi compone un URL di autorizzazione dalle tue impostazioni. Non viene inviato nulla; l'endpoint qui sotto è un segnaposto da sostituire.
Endpoint di autorizzazione
Scope (separati da spazi)
Nuovo verifier
code_verifier ({n} caratteri, tienilo segreto fino al passaggio 4)