La specifica OAuth 2.1 è stata pianificata. Esploriamo le principali differenze tra OAuth 2.0 e OAuth 2.1 e come sono state adottate in Logto.
Da quando OAuth 2.0 (RFC 6749) è stato rilasciato nel 2012, il mondo delle app web e mobile è molto cambiato. Le persone si stanno spostando dai desktop ai dispositivi mobili, e le Single Page Applications (SPA) sono ora di gran moda. Abbiamo anche visto apparire una miriade di nuovi framework e tecnologie web. Con tutti questi cambiamenti, anche le sfide in termini di sicurezza sono aumentate. Per tenere il passo con le ultime tecnologie web, nuovi RFC come Proof Key for Code Exchange (PKCE) sono stati continuamente rilasciati per migliorare OAuth 2.0. È diventato cruciale raggruppare tutte le best practice per le attuali esigenze di sicurezza, ed è per questo che OAuth 2.1 sta arrivando.
Nel futuro OAuth 2.1, l'OAuth Working Group ha l'obiettivo di consolidare tutte le best practice e le raccomandazioni di sicurezza in un unico documento. In Logto, continuiamo ad abbracciare gli ultimi standard e best practice di OAuth. In questo articolo, esploreremo le principali differenze tra OAuth 2.0 e OAuth 2.1 e come sono state adottate in Logto.
Uno dei cambiamenti più significativi in OAuth 2.1 è che Proof Key for Code Exchange (PKCE) è ora obbligatorio per tutti i client OAuth che utilizzano il flusso Authorization Code. PKCE è un'estensione di sicurezza che previene gli attacchi di intercettazione del codice di autorizzazione. È particolarmente utile per le app mobili e le Single Page Applications (SPA) dove non è possibile memorizzare in modo sicuro il secret del client.
I client OAuth possono essere suddivisi in due diverse categorie in base alla loro capacità di memorizzare i secret in modo sicuro:
Client riservati: Questi client possono memorizzare i secret in modo sicuro, come le applicazioni web generate dal server e i server web. Tutte le richieste relative all'autorizzazione vengono effettuate dal lato server e il rischio di esporre il secret del client è basso.
Client pubblici: Questi client non possono memorizzare i secret in modo sicuro, come le app mobili e le SPA. Il secret del client può essere facilmente estratto dal codice lato client, ed è difficile proteggerlo dagli attaccanti.
Per i client pubblici, PKCE è una misura di sicurezza indispensabile. Garantisce che il codice di autorizzazione possa essere scambiato solo dal client che ha iniziato la richiesta di autorizzazione.
PKCE funziona generando un code verifier casuale e una code challenge basata sul code verifier. Il code verifier viene inviato al server di autorizzazione, e la code challenge viene utilizzata per verificare il code verifier durante lo scambio del codice di autorizzazione per un token di accesso.
In OAuth 2.1, PKCE diventa obbligatorio per tutti i client OAuth che utilizzano il flusso Authorization Code, indipendentemente dal loro stato di riservatezza—sia riservati che pubblici. Questo cambiamento fondamentale garantisce una protezione universale contro potenziali attacchi di intercettazione del codice di autorizzazione.
In Logto, il flusso di validazione PKCE è automaticamente attivato sia per i client pubblici che per quelli riservati.
Per le SPA e le app mobili, PKCE è una misura di sicurezza indispensabile per proteggere il flusso di autorizzazione in Logto. Qualsiasi richiesta di autorizzazione priva di una code challenge sarà prontamente rifiutata dal server di autorizzazione di Logto.
Per quanto riguarda i client riservati (app web tradizionali), per migliorare la compatibilità con i sistemi legacy, Logto consente ancora l'omissione della code challenge nella richiesta di autorizzazione. Tuttavia, consigliamo vivamente ai client riservati di adottare PKCE incorporando la code challenge nella richiesta di autorizzazione, seguendo le pratiche dei client pubblici.
Un URI di reindirizzamento (Uniform Resource Identifier) è un endpoint o URL specifico a cui il server di autorizzazione reindirizza l'utente dopo il processo di autenticazione e autorizzazione.
Durante il flusso OAuth, l'applicazione client include un URI di reindirizzamento come parte della richiesta di autorizzazione iniziale. Una volta che l'utente completa il processo di autenticazione, il server di autorizzazione genera una risposta che include un codice di autorizzazione e reindirizza l'utente all'URI di reindirizzamento specificato. Qualsiasi deviazione dall'URI di reindirizzamento originale porterà a una perdita del codice o del token.
La corrispondenza esatta della stringa degli URI di reindirizzamento è stata introdotta per la prima volta nella sezione 4.1 di OAuth 2.0 Security Best Current Practices. Questa pratica garantisce che l'URI di reindirizzamento debba corrispondere esattamente a quello registrato presso il server di autorizzazione. Qualsiasi deviazione dall'URI di reindirizzamento registrato si tradurrà in una risposta di errore.
Abbiamo ricevuto numerose richieste dalla community riguardo all'implementazione della corrispondenza con wildcard per gli URI di reindirizzamento. Sebbene la corrispondenza con wildcard possa offrire comodità per gli sviluppatori che gestiscono più sottodomini o percorsi, in particolare con un gran numero di sottodomini casuali, introduce anche rischi di sicurezza come gli attacchi di reindirizzamento aperto. Per un'illustrazione pratica dei pericoli causati dalla mancanza di validazione degli URI di reindirizzamento, consulta il nostro post sul blog Un breve riepilogo sulla sicurezza OAuth.
In linea con i rigidi standard di sicurezza di OAuth 2.1, Logto utilizza la corrispondenza esatta della stringa degli URI di reindirizzamento. Questa decisione dà priorità alla sicurezza del flusso OAuth. Piuttosto che utilizzare la corrispondenza con wildcard, incoraggiamo gli sviluppatori a registrare tutti i potenziali URI di reindirizzamento presso il server di autorizzazione Logto. Ciò garantisce una convalida accurata degli URI di reindirizzamento e aiuta a mitigare potenziali vulnerabilità di sicurezza.
Il flusso di concessione implicita in OAuth 2.0 è stato progettato per le SPA dove il token di accesso viene restituito direttamente nel frammento di URL dopo che l'utente si è autenticato. Questo metodo era conveniente perché evitava un ulteriore passaggio di scambio di token, permettendo al client di ricevere direttamente il token.
Tuttavia, questa comodità ha i suoi svantaggi. Il token di accesso può essere esposto a parti non autorizzate tramite la cronologia del browser, gli header di riferimento o altri mezzi, rendendo più facile che si verifichino violazioni della sicurezza—soprattutto quando i token di accesso rimangono validi per periodi prolungati. Ad esempio, se la richiesta di autorizzazione viene intercettata da un'entità malintenzionata, questa può facilmente estrarre il token di accesso dal frammento di URL e impersonare l'utente.
Nel OAuth 2.0 Security Best Current Practices, si afferma chiaramente che:
I client NON DEVONO utilizzare l'implicit grant (tipo di risposta "token") o altri tipi di risposta che emettono token di accesso nella risposta di autorizzazione.
Pertanto, l'Implicit Flow è stato ufficialmente rimosso dalla specifica OAuth 2.1.
In Logto, il flusso di autorizzazione con PKCE è l'unico flusso supportato per SPA e app mobili. Il flusso di autorizzazione fornisce un modo più sicuro per ottenere token di accesso scambiando il codice di autorizzazione.
Il grant delle credenziali del proprietario della risorsa (ROPC) consente al client di scambiare il nome utente e la password dell'utente per un token di accesso. È stato introdotto per la prima volta nella specifica OAuth 2.0 come modo per supportare applicazioni legacy come l'autenticazione HTTP di base o applicazioni native legacy che non potevano utilizzare flussi OAuth più sicuri.
Il tipo di grant ROPC è stato segnato come non raccomandato nella specifica OAuth 2.0 a causa dei rischi per la sicurezza. Le credenziali dell'utente vengono esposte all'applicazione client, il che può portare a potenziali violazioni della sicurezza. L'applicazione client può memorizzare le credenziali dell'utente, e se il client viene compromesso, le credenziali dell'utente possono essere esposte agli attaccanti.
Successivamente, nella sezione 2.4 del OAuth 2.0 Security Best Current Practices, la proibizione del tipo di grant ROPC è stata ulteriormente rafforzata come NON DEVE essere utilizzato. Di conseguenza, il tipo di grant ROPC è stato rimosso dalla specifica OAuth 2.1.
A causa degli alti rischi di sicurezza associati al tipo di grant ROPC, Logto non lo ha mai supportato. Se stai ancora utilizzando il flusso diretto delle credenziali utente nelle tue applicazioni legacy, ti consigliamo vivamente di migrare a un metodo più sicuro, come il flusso di autorizzazione o il grant delle credenziali del client. Logto offre vari SDK e tutorial per aiutarti a integrare questi flussi OAuth sicuri nelle tue applicazioni senza difficoltà.
Comprendiamo che gli sviluppatori potrebbero voler progettare o ospitare autonomamente la propria interfaccia di accesso utente per la migliore esperienza del prodotto. In Logto, offriamo una gamma di opzioni di personalizzazione della sign-in experience (SIE), incluse impostazioni di branding e CSS personalizzato. Inoltre, abbiamo diversi progetti in corso, come bring-your-own UI e accesso diretto, per fornire maggiore flessibilità agli sviluppatori nel portare la propria interfaccia di accesso mantenendo la sicurezza del flusso OAuth.
OAuth 2.1 è l'ultimo aggiornamento al protocollo OAuth, orientato ad affrontare le sfide di sicurezza di oggi abbracciando le esigenze delle app web e mobile moderne. Il gruppo di lavoro OAuth sta attivamente aggiornando e perfezionando OAuth 2.1 per garantire che rispetti gli ultimi standard di sicurezza e le best practice. L'ultima bozza, OAuth 2.1 11, è stata rilasciata a maggio 2024, segnando un progresso significativo verso la sua finalizzazione. Con l'ampia adozione all'orizzonte, raccomandiamo vivamente a tutti di seguire le best practice delineate in OAuth 2.1 per migliorare la sicurezza e migliorare l'esperienza dell'utente.