OAuth è uguale all'autenticazione?

No. OAuth è un'autorizzazione: concede al client l'autorizzazione per accedere alle risorse. OpenID Connect, basato su OAuth, aggiunge l'autenticazione. "Accedi con Google" è OIDC; "Connetti Google Calendar" può dipendere dal fatto che l'app abbia bisogno di sapere chi sei o semplicemente di accedere ai tuoi dati.

Dovrei utilizzare OAuth o memorizzare le password?

Utilizza OAuth ove possibile. Memorizzare le password degli utenti significa ereditare tutta la responsabilità di hashing, salt, risposta alle violazioni, recupero della password e 2FA. La delega a Google/Apple/Microsoft/GitHub tramite OAuth scarica tutto ciò. Il compromesso è che i tuoi utenti necessitano di account presso tali fornitori.

Perché i token OAuth possono essere revocati ma le password no?

I token fanno riferimento a una voce nel database del server di autorizzazione. La revoca dell'immissione invalida immediatamente il token. Le password sono conoscenza: puoi ruotare la password e forzare la riautenticazione, ma la vecchia password rimane valida finché non lo fai.

Qual è la differenza tra OAuth 2.0 e OAuth 1.0?

OAuth 1.0 (2007) utilizzava firme crittografiche su ogni richiesta. OAuth 2.0 (2012) si basa su TLS per la sicurezza del trasporto e utilizza token al portatore. OAuth 2.0 è più semplice da implementare e viene fornito in quasi tutte le API moderne; OAuth 1.0 è essenzialmente deprecato.

I token OAuth sono pericolosi se trapelati?

Sì, chiunque abbia il token ha l'accesso concesso fino alla scadenza o alla revoca. Mitigazioni: durata breve dei token di accesso (tipicamente 1 ora), token di aggiornamento archiviati in modo più sicuro, minimizzazione dell'ambito, registrazione di controllo. Tratta i token di accesso con la stessa cura delle password durante il loro periodo di validità.

Spiegazione di OAuth 2.0: come funziona effettivamente "Accedi con Google".

Ogni pulsante "Accedi con Google", ogni collegamento "Connetti il tuo account Twitter", ogni integrazione API tra servizi moderni si basa su OAuth. Il protocollo sostituisce la condivisione delle password con un flusso di token e schermate di consenso, e la comprensione delle parti in movimento demistifica una categoria di attacchi e comodità.

Il corpo completo dell'articolo è fornito in inglese di seguito.

OAuth 2.0 è un framework di autorizzazione che consente a un'applicazione di ottenere un accesso limitato alle risorse di un'altra applicazione per conto di un utente, senza mai vedere la password dell'utente. Il classico caso d'uso: un'app di calendario che deve leggere il tuo Google Calendar non dovrebbe richiederti di fornirle la tua password Google. OAuth ti consente invece di concedere all'app un token revocabile con ambito.

LGli attori

Quattro ruoli in un flusso OAuth:

Proprietario della risorsa: tu, l'utente con dati da qualche parte
Client: l'applicazione che desidera accedere (ad esempio, un visualizzatore di calendari di terze parti)
Server di autorizzazione: il servizio che ti autentica ed emette token (ad esempio, l'endpoint OAuth di Google)
Server di risorse: l'API che contiene i tuoi dati (ad esempio, Google Calendar API)

Lil flusso del codice di autorizzazione

Lil flusso lato server standard, semplificato:

Fai clic su "Connetti Google Calendar" nell'app client.
Lil client reindirizza il browser al server di autorizzazione di Google con i parametri: client_id, reindirizzamento_uri, ambito (calendar.read), stato (CSRF token).
Effettui l'autenticazione su Google se non hai già effettuato l'accesso.
Google ti mostra una schermata di consenso: "CalendarViewer vuole leggere il tuo calendario. Consenti?"
Fai clic su Consenti. Google reindirizza il browser all'uri_redirect del client con un codice di autorizzazione monouso.
LIl codice lato server del client scambia il codice di autorizzazione (più il relativo segreto client) con un token di accesso chiamando direttamente l'endpoint del token di Google.
LIl client utilizza il token di accesso per chiamare l'API di Google Calendar per tuo conto.
Quando il token di accesso scade (in genere un'ora), il client utilizza un token di aggiornamento per ottenerne uno nuovo senza disturbarti.

La proprietà di sicurezza cruciale: la tua password non tocca mai l'app client. Il client riceve un token con ambito che puoi revocare in qualsiasi momento nel dashboard dell'account Google.

OAuth 2.0 vs OAuth 2.1 vs OIDC

OAuth 2.0 è lo standard del 2012 (RFC 6749). Da allora sono stati aggiunti diversi RFC di estensione e documenti sulle migliori pratiche.
OAuth 2.1 (in bozza a partire dal 2026) consolida le migliori pratiche attuali in un'unica specifica: PKCE obbligatorio, flusso implicito rimosso, ecc.
OpenID Connect (OIDC) è un livello di identità sopra OAuth 2.0. Solo OAuth fornisce un token di accesso opaco; OIDC aggiunge un token ID (un JWT) che autentica l'utente. La maggior parte dei pulsanti "Accedi con..." utilizza OIDC, non OAuth semplice.

Li tipi di concessione

OAuth 2.0 definisce diversi flussi per diversi scenari:

Codice di autorizzazione: il flusso lato server standard descritto sopra. Con estensione PKCE, utilizzata anche da app mobili e SPA.
Implicit Flow (deprecato): token di accesso emessi direttamente tramite frammento URL. Vulnerabile alla perdita di token; sostituito da Codice di autorizzazione + PKCE.
Credenziali password proprietario risorsa (utilizzato raramente): il client raccoglie la password dell'utente e la scambia con un token. Da utilizzare solo in scenari di migrazione legacy.
Credenziali client: per computer in cui non è presente alcun utente. Il client si autentica e ottiene un token per le proprie risorse.
Device Code — per dispositivi senza browser (TV, IoT). Il dispositivo mostra un codice; l'utente autorizza da un telefono o laptop.
Refresh Token: scambia un token di aggiornamento di lunga durata con un nuovo token di accesso senza interazione da parte dell'utente.

PKCE: l'estensione indispensabile

PKCE (Proof Key for Code Exchange, pronunciato "pixie") previene gli attacchi di intercettazione del codice di autorizzazione. Il client genera un segreto casuale, ne esegue l'hashing e invia l'hash nella richiesta di autorizzazione. Quando si scambia il codice, invia il segreto originale. Il server di autorizzazione verifica le corrispondenze hash. Qualsiasi utente malintenzionato che intercetta il codice non può scambiarlo senza il segreto originale.

PKCE è ora considerato obbligatorio per tutti i client OAuth: pubblici (browser, dispositivi mobili) e riservati (lato server).

Scopes

Token vengono emessi con ambiti specifici: le azioni che possono eseguire. Gli ambiti tipici di Google assomigliano a https://www.googleapis.com/auth/calendar.readonly. Il client richiede ambiti; l'utente li vede nella schermata di consenso e approva o rifiuta. Il principio del privilegio minimo: chiedi solo gli ambiti di cui hai effettivamente bisogno.

Attacchi OAuth comuni

Reindirizzamento aperto. Un parametro reindirizzamento_uri configurato in modo errato consente a un utente malintenzionato di reindirizzare il codice di autorizzazione sul proprio server.
Parametro di stato omissione. Senza un valore di stato legato alla sessione dell'utente, I flussi OAuth sono vulnerabili a CSRF: un utente malintenzionato induce con l'inganno la vittima a completare un flusso OAuth che collega l'account dell'utente malintenzionato alla sessione della vittima.
T Perdita di token nella cronologia del browser (il principale punto debole del flusso implicito).
Turto di token tramite XSS. Se l'app client memorizza i token in localStorage e presenta una vulnerabilità XSS, gli utenti malintenzionati possono rubarli.
Phishing nella schermata di consenso. Un utente malintenzionato registra un client OAuth dannoso che richiede ambiti sensibili; l'utente, condizionato a fare clic su "Consenti" nelle schermate di consenso, concede l'accesso senza controllo.

Cosa fare come utente

Controlla periodicamente le app collegate nelle impostazioni dell'account Google/Apple/Microsoft/Facebook/GitHub. Revoca quelli che non utilizzi.
Leggi gli ambiti della schermata di consenso prima di concedere l'accesso. "Gestisci il tuo calendario" è diverso da "Visualizza il tuo calendario".
Sii scettico nei confronti delle richieste OAuth provenienti da app che non riconosci, anche se vengono visualizzate durante un flusso di lavoro familiare.

Domande frequenti

OAuth è uguale all'autenticazione?: No. OAuth è un'autorizzazione: concede al client l'autorizzazione per accedere alle risorse. OpenID Connect, basato su OAuth, aggiunge l'autenticazione. "Accedi con Google" è OIDC; "Connetti Google Calendar" può dipendere dal fatto che l'app abbia bisogno di sapere chi sei o semplicemente di accedere ai tuoi dati.
Dovrei utilizzare OAuth o memorizzare le password?: Utilizza OAuth ove possibile. Memorizzare le password degli utenti significa ereditare tutta la responsabilità di hashing, salt, risposta alle violazioni, recupero della password e 2FA. La delega a Google/Apple/Microsoft/GitHub tramite OAuth scarica tutto ciò. Il compromesso è che i tuoi utenti necessitano di account presso tali fornitori.
Perché i token OAuth possono essere revocati ma le password no?: I token fanno riferimento a una voce nel database del server di autorizzazione. La revoca dell'immissione invalida immediatamente il token. Le password sono conoscenza: puoi ruotare la password e forzare la riautenticazione, ma la vecchia password rimane valida finché non lo fai.
Qual è la differenza tra OAuth 2.0 e OAuth 1.0?: OAuth 1.0 (2007) utilizzava firme crittografiche su ogni richiesta. OAuth 2.0 (2012) si basa su TLS per la sicurezza del trasporto e utilizza token al portatore. OAuth 2.0 è più semplice da implementare e viene fornito in quasi tutte le API moderne; OAuth 1.0 è essenzialmente deprecato.
I token OAuth sono pericolosi se trapelati?: Sì, chiunque abbia il token ha l'accesso concesso fino alla scadenza o alla revoca. Mitigazioni: durata breve dei token di accesso (tipicamente 1 ora), token di aggiornamento archiviati in modo più sicuro, minimizzazione dell'ambito, registrazione di controllo. Tratta i token di accesso con la stessa cura delle password durante il loro periodo di validità.