In che modo OAuth 2 è diverso da OAuth 1?

In termini molto semplici, qualcuno può spiegare la differenza tra OAuth 2 e OAuth 1?

OAuth 1 è obsoleto ora? Dovremmo implementare OAuth 2? Non vedo molte implementazioni di OAuth 2; molti usano ancora OAuth 1, il che mi fa dubitare che OAuth 2 sia pronto per l'uso. È?

Eran Hammer-Lahav ha fatto un ottimo lavoro nel spiegare la maggior parte delle differenze nel suo articolo Presentazione di OAuth 2.0 . Per riassumere, ecco le differenze principali:

Più flussi OAuth per consentire un supporto migliore per le applicazioni non basate su browser. Questa è una delle principali critiche contro OAuth da parte di applicazioni client che non erano basate su browser. Ad esempio, in OAuth 1.0, le applicazioni desktop o le applicazioni per telefoni cellulari dovevano indirizzare l'utente ad aprire il proprio browser al servizio desiderato, autenticarsi con il servizio e copiare il token dal servizio all'applicazione. La critica principale qui è contro l'esperienza dell'utente. Con OAuth 2.0, ora ci sono nuovi modi in cui un'applicazione può ottenere l'autorizzazione per un utente.

OAuth 2.0 non richiede più la crittografia delle applicazioni client. Questo ritorna alla vecchia API Auth di Twitter, che non richiedeva l'applicazione ai token hash HMAC e alle stringhe di richiesta. Con OAuth 2.0, l'applicazione può effettuare una richiesta utilizzando solo il token emesso su HTTPS.

Le firme di OAuth 2.0 sono molto meno complicate. Niente più analisi, ordinamento o codifica speciali.

I token di accesso OAuth 2.0 sono "di breve durata". In genere, i token di accesso OAuth 1.0 potrebbero essere archiviati per un anno o più (Twitter non li lascia mai scadere). OAuth 2.0 ha il concetto di token di aggiornamento. Anche se non sono del tutto sicuro di cosa siano, la mia ipotesi è che i token di accesso possano avere vita breve (ovvero basati sulla sessione) mentre i token di aggiornamento possono essere "tempo di vita". Utilizzeresti un token di aggiornamento per acquisire un nuovo token di accesso invece che autorizzare nuovamente l'autorizzazione della tua applicazione.

Infine, OAuth 2.0 dovrebbe avere una netta separazione dei ruoli tra il server responsabile della gestione delle richieste OAuth e il server che gestisce l'autorizzazione dell'utente. Maggiori informazioni in merito sono dettagliate nel suddetto articolo.

Vedo grandi risposte qui, ma quello che mi mancava erano alcuni diagrammi e da quando ho dovuto lavorare con Spring Framework mi sono imbattuto nella loro spiegazione .

Trovo molto utili i seguenti diagrammi. Illustrano la differenza nella comunicazione tra le parti con OAuth2 e OAuth1.

OAuth 2

OAuth 1

Le spiegazioni precedenti sono tutte IMO eccessivamente dettagliate e complicate. In parole povere, OAuth 2 delega la sicurezza al protocollo HTTPS. OAuth 1 non lo richiedeva e di conseguenza disponeva di metodi alternativi per affrontare vari attacchi. Questi metodi richiedevano all'applicazione di impegnarsi in determinati protocolli di sicurezza che sono complicati e possono essere difficili da implementare. Pertanto, è più semplice affidarsi all'HTTPS per la sicurezza in modo che gli sviluppatori di applicazioni non debbano preoccuparsene.

Per quanto riguarda le altre domande, la risposta dipende. Alcuni servizi non vogliono richiedere l'uso di HTTPS, sono stati sviluppati prima di OAuth 2 o hanno altri requisiti che potrebbero impedire loro di utilizzare OAuth 2. Inoltre, si è discusso molto sul protocollo OAuth 2 stesso. Come puoi vedere, Facebook, Google e pochi altri hanno versioni leggermente diverse dei protocolli implementati. Quindi alcune persone restano fedeli a OAuth 1 perché è più uniforme tra le diverse piattaforme. Di recente, il protocollo OAuth 2 è stato finalizzato ma non abbiamo ancora visto come sarà adottata la sua adozione.

Nota che esistono seri argomenti di sicurezza contro l'utilizzo di Oauth 2:

un articolo desolante

e uno più tecnico

Nota che provengono dall'autore principale di Oauth 2.

Punti chiave:

• Oauth 2 non offre sicurezza oltre a SSL mentre Oauth 1 è indipendente dal trasporto.

• in un certo senso SSL non è sicuro in quanto il server non verifica la connessione e le librerie client comuni rendono facile ignorare gli errori.

  Il problema con SSL / TLS è che quando non si verifica il certificato sul lato client, la connessione funziona ancora. Ogni volta che ignorare un errore porta al successo, gli sviluppatori faranno proprio questo. Il server non ha modo di imporre la verifica del certificato e, anche se potesse, un attaccante non lo farà sicuramente.

• puoi sgretolare tutta la tua sicurezza, il che è molto più difficile da fare in OAuth 1.0:

  Il secondo potenziale problema comune sono i refusi. Lo considereresti un disegno appropriato quando ometti un personaggio (la 's' in 'https') annulla l'intera sicurezza del token? O forse inviare la richiesta (tramite una connessione SSL / TLS valida e verificata) a una destinazione errata (dire " http://gacebook.com "?). Ricorda, essere in grado di usare i token di portatore di OAuth dalla riga di comando è stato chiaramente un promotore dei token di portatori di token di portatore di casi d'uso promossi.

La sicurezza del protocollo OAuth 1.0 ( RFC 5849 ) si basa sul presupposto che una chiave segreta incorporata in un'applicazione client può essere mantenuta riservata. Tuttavia, il presupposto è ingenuo.

In OAuth 2.0 ( RFC 6749 ), un'applicazione client così ingenua è chiamata client confidenziale . D'altra parte, un'applicazione client in un ambiente in cui è difficile mantenere una chiave segreta riservata viene chiamata client pubblico . Vedi 2.1. Tipi di client per i dettagli.

In tal senso, OAuth 1.0 è una specifica solo per i client riservati.

" OAuth 2.0 e la strada per l'inferno " afferma che OAuth 2.0 è meno sicuro, ma non esiste alcuna differenza pratica nel livello di sicurezza tra i client OAuth 1.0 e i client confidenziali OAuth 2.0. OAuth 1.0 richiede il calcolo della firma, ma non migliora la sicurezza se è già garantito che una chiave segreta sul lato client può essere mantenuta riservata. La firma informatica è solo un calcolo ingombrante senza alcun miglioramento pratico della sicurezza. Voglio dire, rispetto alla semplicità che un client OAuth 2.0 si connette a un server tramite TLS e si presenta client_ide client_secret, non si può dire che il calcolo ingombrante sia migliore in termini di sicurezza.

Inoltre, RFC 5849 (OAuth 1.0) non menziona nulla sui redirector aperti mentre RFC 6749 (OAuth 2.0) lo fa. Cioè, il oauth_callbackparametro di OAuth 1.0 può diventare una falla di sicurezza.

Pertanto, non credo che OAuth 1.0 sia più sicuro di OAuth 2.0.

La sicurezza di OAuth 1.0 si basa sul calcolo delle firme. Una firma viene calcolata utilizzando una chiave segreta in cui una chiave segreta è una chiave condivisa per HMAC-SHA1 ( RFC 5849, 3.4.2 ) o una chiave privata per RSA-SHA1 ( RFC 5849, 3.4.3 ). Chiunque conosca la chiave segreta può calcolare la firma. Quindi, se la chiave segreta è compromessa, la complessità del calcolo della firma è insignificante per quanto complessa.

Ciò significa che la sicurezza di OAuth 1.0 non si basa sulla complessità e sulla logica del calcolo della firma, ma semplicemente sulla riservatezza di una chiave segreta. In altre parole, ciò che è necessario per la sicurezza di OAuth 1.0 è solo la condizione che una chiave segreta possa essere mantenuta riservata. Questo può sembrare estremo, ma il calcolo della firma non aggiunge alcun miglioramento della sicurezza se la condizione è già soddisfatta.

Allo stesso modo, i client riservati di OAuth 2.0 fanno affidamento sulla stessa condizione. Se la condizione è già soddisfatta, c'è qualche problema nella creazione di una connessione protetta tramite TLS e nell'invio client_ide client_secreta un server di autorizzazione tramite la connessione protetta? C'è qualche grande differenza nel livello di sicurezza tra i client riservati di OAuth 1.0 e OAuth 2.0 se entrambi si affidano alla stessa condizione?

Non riesco a trovare alcun motivo valido per OAuth 1.0 per incolpare OAuth 2.0. Il fatto è semplicemente che (1) OAuth 1.0 è solo una specifica solo per i client confidenziali e (2) OAuth 2.0 ha semplificato il protocollo per i client confidenziali e anche i client pubblici supportati . Indipendentemente dal fatto che sia noto o meno, le applicazioni per smartphone sono classificate come client pubblici ( RFC 6749, 9 ), che beneficiano di OAuth 2.0.

Le firme OAuth 2.0 non sono necessarie per le chiamate API effettive una volta generato il token. Ha un solo token di sicurezza.

OAuth 1.0 richiede al client di inviare due token di sicurezza per ciascuna chiamata API e di utilizzare entrambi per generare la firma. Richiede che gli endpoint delle risorse protette abbiano accesso alle credenziali del client per convalidare la richiesta.

Qui viene descritta la differenza tra OAuth 1.0 e 2.0 e come funzionano entrambi.

OAuth 2 è apparentemente una perdita di tempo (dalla bocca di qualcuno che ne è stato fortemente coinvolto):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Dice (modificato per brevità e in grassetto per enfasi):

... Non posso più essere associato allo standard OAuth 2.0. Ho rinunciato al mio ruolo di autore principale e redattore, ho ritirato il mio nome dalle specifiche e ho lasciato il gruppo di lavoro. Rimuovere il mio nome da un documento su cui ho lavorato scrupolosamente per tre anni e oltre due dozzine di progetti non è stato facile. Decidere di passare da uno sforzo che ho condotto per oltre cinque anni è stato angosciante.

... Alla fine, sono giunto alla conclusione che OAuth 2.0 è un protocollo non valido. WS- * male. È abbastanza brutto che non voglio più essere associato ad esso. ... Rispetto a OAuth 1.0, la specifica 2.0 è più complessa, meno interoperabile, meno utile, più incompleta e, soprattutto, meno sicura.

Per essere chiari, OAuth 2.0 a portata di mano di uno sviluppatore con una profonda conoscenza della sicurezza web risulterà probabilmente in un'implementazione sicura. Tuttavia, per mano della maggior parte degli sviluppatori - come è stata l'esperienza degli ultimi due anni - 2.0 probabilmente produrrà implementazioni non sicure.

Se hai bisogno di qualche spiegazione avanzata devi leggere entrambe le specifiche:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Se hai bisogno di una chiara spiegazione delle differenze di flusso, questo potrebbe aiutarti:

OAuth 1.0 Flow

1. L'applicazione client si registra con il provider, come Twitter.
2. Twitter fornisce al cliente un "segreto del consumatore" unico per quell'applicazione.
3. L'app client firma tutte le richieste OAuth su Twitter con il suo unico "segreto del consumatore".
4. Se una delle richieste OAuth non è corretta, i dati mancanti o firmati in modo errato, la richiesta verrà respinta.

Flusso OAuth 2.0

1. L'applicazione client si registra con il provider, come Twitter.
2. Twitter fornisce al client un "segreto client" unico per quell'applicazione.
3. L'applicazione client include "client secret" con ogni richiesta comunemente come intestazione http.
4. Se una delle richieste OAuth non è corretta, i dati mancanti o contengono un segreto errato, la richiesta verrà respinta.

Fonte: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

OAuth 2.0 promette di semplificare le cose nei seguenti modi:

1. SSL è richiesto per tutte le comunicazioni richieste per generare il token. Questa è una grande diminuzione della complessità perché quelle firme complesse non sono più necessarie.
2. Le firme non sono necessarie per le chiamate API effettive una volta che il token è stato generato: qui è anche fortemente raccomandato SSL.
3. Una volta generato il token, OAuth 1.0 richiede che il client invii due token di sicurezza su ogni chiamata API e utilizzi entrambi per generare la firma. OAuth 2.0 ha un solo token di sicurezza e non è richiesta alcuna firma.
4. È chiaramente specificato quali parti del protocollo sono implementate dal "proprietario delle risorse", quale è il server effettivo che implementa l'API e quali parti possono essere implementate da un "server di autorizzazione" separato. Ciò renderà più semplice per prodotti come Apigee offrire supporto OAuth 2.0 alle API esistenti.

Fonte: http://blog.apigee.com/detail/oauth_differences

Da un punto di vista della sicurezza, sceglierei OAuth 1. Vedi OAuth 2.0 e la strada per l'inferno

citazione da quel link: "Se stai usando 1.0 con successo, ignora 2.0. Non offre alcun valore reale su 1.0 (suppongo che i tuoi sviluppatori client abbiano già capito le firme 1.0 ormai).

Se sei nuovo in questo spazio e ti consideri un esperto di sicurezza, usa 2.0 dopo un attento esame delle sue funzionalità. Se non sei un esperto, usa 1.0 o copia l'implementazione 2.0 di un provider di cui ti fidi per farlo nel modo giusto (i documenti API di Facebook sono un buon punto di partenza). 2.0 è meglio per grandi dimensioni, ma se stai eseguendo un'operazione importante, probabilmente avrai alcuni esperti di sicurezza sul posto per capire tutto per te. "