Italiano

oauth
flusso implicito
codice di autorizzazione
PKCE

Flusso implicito vs. Flusso del codice di autorizzazione: perché il flusso implicito è morto?

Perché esiste un "Flusso del codice di autorizzazione" in OAuth 2.0 quando abbiamo già il "Flusso implicito"? Esploriamo i dettagli di questi due tipi di autorizzazione e scopriamo perché dovresti evitare di utilizzare il flusso implicito.

Darcy Ye

Developer

1/3/2024

Smetti di sprecare settimane sull'autenticazione degli utenti

Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.

Inizia ora

Il Flusso del codice di autorizzazione e il Flusso implicito sono due dei tipi di autorizzazione più comunemente utilizzati in OAuth 2.0, che consentono una autorizzazione dell'utente sicura ed efficiente per le applicazioni web. Entrambi i flussi implementano un processo di autorizzazione che permette agli utenti di concedere accesso alle applicazioni senza esporre direttamente le loro credenziali. Il Flusso implicito è stato inizialmente sviluppato per affrontare le limitazioni del browser, ma con l'avvento delle moderne tecnologie web, il Flusso del codice di autorizzazione è diventato la scelta preferita da molti sviluppatori grazie alle sue caratteristiche di sicurezza avanzate.

In questo articolo, esploreremo le differenze tra questi due tipi di autorizzazione ed esamineremo perché dovresti evitare di utilizzare il Flusso implicito a favore del Flusso del codice di autorizzazione.

Cos'è OAuth 2.0?

Prima di approfondire i dettagli di questi due tipi di autorizzazione, comprendiamo innanzitutto cos'è OAuth 2.0 e perché è essenziale per le moderne applicazioni web.

Quando si parla di OAuth, ci si riferisce di solito a OAuth 2.0, noto come "Open Authorization", un protocollo consolidato che consente ai siti web o alle applicazioni di utilizzare risorse di altri servizi web per conto di un utente. Ha succeduto OAuth 1.0 nel 2012 e da allora è diventato lo standard ampiamente accettato per l'autorizzazione digitale. OAuth 2.0 è progettato per fornire accesso controllato agli utenti, permettendo alle applicazioni client di ottenere permessi specifici per interagire con risorse rappresentative dell'utente, tutto senza rivelare le credenziali di accesso dell'utente.

Sebbene sia principalmente utilizzato in ambienti web, il framework di OAuth 2.0 si estende anche a varie forme di client. Questo include applicazioni basate sul browser, applicazioni web lato server, applicazioni native o mobili e persino dispositivi interconnessi, dettagliando l'approccio per gestire l'accesso delegato su queste piattaforme. Introduce il concetto di "tipi di autorizzazione" per definire il processo di autorizzazione tra l'applicazione client, l'utente e il server di autorizzazione. Questi tipi di autorizzazione sono utilizzati per determinare come l'applicazione client può ottenere un token di accesso per accedere alle risorse dell'utente. I tipi di autorizzazione più comuni in OAuth 2.0 sono:

Codice di autorizzazione: Ideale per tutti i tipi di applicazioni, specialmente le applicazioni web lato server, dove l'applicazione client può scambiare un codice di autorizzazione per un token di accesso e gestire i token in modo sicuro.
Implicito: Un flusso semplificato, progettato per applicazioni basate sul browser, senza un componente server sicuro. È stato creato per consegnare rapidamente i token alle applicazioni client. Ma ora è ampiamente deprecato a causa di problemi di sicurezza.
Credenziali password del proprietario della risorsa: Questo tipo consente all'applicazione client di richiedere direttamente un token di accesso inviando le credenziali dell'utente (nome utente e password). Poiché l'applicazione client ha un accesso diretto alle credenziali dell'utente, questo tipo di autorizzazione è considerato anch'esso deprecato e dovrebbe essere evitato in tutte le circostanze.
Credenziali client: Utilizzato per la comunicazione macchina-a-macchina dove l'applicazione stessa è il client. Comporta l'autenticazione dell'applicazione con il server di autorizzazione e la richiesta di un token di accesso per accedere alle proprie risorse o a quelle di un altro servizio.

Cos'è il flusso implicito?

Il flusso implicito è un flusso semplificato di OAuth 2.0 dove il token di accesso viene restituito direttamente al client nell'URI di reindirizzamento, senza un ulteriore passaggio per scambiare un codice di autorizzazione per un token. È stato originariamente progettato per le applicazioni web che non potevano effettuare richieste lato server al endpoint dei token a causa delle restrizioni del browser.

Come funziona il flusso implicito?

L'utente clicca un pulsante o un link nell'applicazione client per avviare il processo di autenticazione.
L'applicazione client reindirizza l'utente al server di autorizzazione per autenticarsi, includendo l'ambito di accesso desiderato.
Il server di autorizzazione chiede agli utenti di accedere e concedere il permesso all'applicazione client.
Dopo l'autenticazione e l'autorizzazione con successo, il server di autorizzazione reindirizza il browser dell'utente all'URI di reindirizzamento specificato dal cliente, con il token di accesso incluso nel frammento URL.
L'applicazione client estrae il token di accesso dal frammento URL e lo utilizza per accedere alle risorse dell'utente sul server di risorse.

Rischi di sicurezza del flusso implicito

Il flusso implicito presenta diverse vulnerabilità di sicurezza:

Esposizione del token: Il token di accesso viene restituito direttamente al client nel frammento URL, che può essere facilmente intercettato da parti malintenzionate. Questo espone il token di accesso a un potenziale furto e uso improprio.
Attacchi CSRF: Il flusso implicito è suscettibile agli attacchi Cross-Site Request Forgery (CSRF), dove siti web malintenzionati possono ingannare gli utenti nel concedere accessi non autorizzati ai loro account.

A causa di questi problemi di sicurezza, il flusso implicito non è più raccomandato per le applicazioni web moderne. Invece, il flusso del codice di autorizzazione con PKCE (Proof Key for Code Exchange) è la scelta preferita per un'autorizzazione utente sicura.

Cos'è il flusso del codice di autorizzazione?

Il flusso del codice di autorizzazione, d'altra parte, è un flusso di OAuth 2.0 più sicuro che separa il processo di autorizzazione in due fasi: l'applicazione client prima ottiene un codice di autorizzazione dal server di autorizzazione, poi scambia il codice per un token di accesso. Questo flusso è stato inizialmente progettato per le applicazioni web lato server che possono archiviare in modo sicuro le credenziali client e gestire i token di accesso. Con l'introduzione dell'estensione PKCE, il flusso del codice di autorizzazione può ora essere utilizzato anche in applicazioni basate su browser.

Come funziona il flusso del codice di autorizzazione per i clienti privati con componente lato server?

L'utente clicca un pulsante o un link nell'applicazione client per avviare il processo di autenticazione.
L'applicazione client reindirizza l'utente al server di autorizzazione per autenticarsi con l'ambito di accesso desiderato.
Il server di autorizzazione chiede agli utenti di accedere e concedere il permesso all'applicazione client.
Dopo l'autenticazione e l'autorizzazione con successo, il server di autorizzazione restituisce un codice di autorizzazione al client.
L'applicazione client scambia in modo sicuro il codice di autorizzazione per un token di accesso effettuando una richiesta server-a-server al endpoint dei token utilizzando le sue credenziali client.
Il server di autorizzazione convalida il codice di autorizzazione e le credenziali client e restituisce un token di accesso al client.
L'applicazione client utilizza il token di accesso per accedere alle risorse dell'utente sul server di risorse.

Come funziona il flusso del codice di autorizzazione per i clienti pubblici con PKCE?

L'utente clicca un pulsante o un link nell'applicazione client per avviare il processo di autenticazione.
L'applicazione client genera un verificatore di codice e una sfida di codice.
L'applicazione client reindirizza l'utente al server di autorizzazione per autenticarsi con la sfida di codice.
Il server di autorizzazione memorizza la sfida di codice per una verifica successiva.
L'utente si autentica e approva l'accesso all'applicazione client.
Il server di autorizzazione restituisce un codice di autorizzazione al client.
L'applicazione client scambia il codice di autorizzazione per un token di accesso effettuando una richiesta server-a-server al endpoint dei token utilizzando il verificatore di codice.
Il server di autorizzazione convalida il codice di autorizzazione e il verificatore di codice rispetto alla sfida di codice memorizzata.
Il server di autorizzazione restituisce un token di accesso al client.
L'applicazione client utilizza il token di accesso per accedere alle risorse dell'utente sul server di risorse.

Scopri di più sul flusso PKCE.