In che modo OAuth 2 protegge da cose come gli attacchi replay usando il token di sicurezza?

564

A quanto mi risulta, la seguente catena di eventi si verifica in OAuth 2 per Site-Apoter accedere alle informazioni dell'utente da Site-B.

Site-Asi registra Site-Be ottiene un segreto e un ID.
Quando l' Utente dice Site-Adi accedere Site-B, l' Utente viene inviato Site-Bdove dice Site-Bche vorrebbero davvero concedere Site-Aautorizzazioni a informazioni specifiche.
Site-Breindirizza l' utente a Site-A, insieme a un codice di autorizzazione.
Site-Aquindi passa quel codice di autorizzazione insieme al suo segreto a Site-Bin cambio di un token di sicurezza.
Site-Aquindi effettua richieste per Site-Bconto dell'utente raggruppando il token di sicurezza insieme alle richieste.

Come funziona tutto ciò in termini di sicurezza e crittografia, ad alto livello? In che modo OAuth 2 protegge da cose come gli attacchi replay usando il token di sicurezza?

oauth-2.0

— William Jones
fonte

49

oauth2 semplicemente spiegato qui: gist.github.com/mziwisky/10079157

— Paolo

4

Leggi la specifica: tools.ietf.org/html/rfc6749 Potresti essere sorpreso di quanto sia comprensibile. È anche corretto che potrebbe non essere così male.

— Kris Vandermotten,

1

Questa domanda e le sue (attuali) risposte si concentrano tutte su un particolare "tipo di concessione" in OAuth 2.0 (ovvero code) ma ci sono altri tipi di concessione definiti in OAuth 2.0 che sono rilevanti per diversi casi d'uso (ad esempio quelli non correlati all'utente).

— Hans Z.,

4

Oh, perché non sostituire "Sito B" con qualcosa di più leggibile come "Sito IdProvider"?

— Yurii,

1379

Come funziona OAuth 2.0 nella vita reale:

Stavo guidando dalla panetteria di Olaf mentre andavo al lavoro quando ho visto la ciambella più deliziosa alla finestra - voglio dire, la cosa gocciolava bontà al cioccolato. Quindi sono entrato e ho chiesto "Devo avere quella ciambella!". Ha detto "sicuro che saranno $ 30".

Sì, lo so, $ 30 per una ciambella! Deve essere delizioso! Ho preso il mio portafoglio quando all'improvviso ho sentito lo chef urlare "NO! Nessuna ciambella per te". Ho chiesto: perché? Ha detto che accetta solo bonifici bancari.

Sul serio? Sì, era serio. Mi sono quasi allontanato proprio lì, ma poi la ciambella mi ha chiamato: "Mangiami, sono delizioso ...". Chi sono io per disobbedire agli ordini da una ciambella? Ho detto ok.

Mi ha consegnato un biglietto con il suo nome (lo chef, non la ciambella): "Digli che Olaf ti ha inviato". Il suo nome era già sulla nota, quindi non so quale fosse il punto di dire, ma ok.

Ho guidato un'ora e mezza alla mia banca. Ho consegnato il biglietto al cassiere; Le ho detto che Olaf mi ha mandato. Mi ha dato uno di quegli sguardi, il tipo che dice "so leggere".

Ha preso il mio biglietto, ha chiesto il mio documento d'identità, mi ha chiesto quanti soldi fosse giusto per dargli. Le ho detto $ 30 dollari. Ha fatto degli scarabocchi e mi ha consegnato un altro biglietto. Questo aveva un sacco di numeri, immagino che sia così che tengono traccia delle note.

A quel punto sto morendo di fame. Mi sono precipitato fuori di lì, un'ora e mezza dopo ero di ritorno, in piedi davanti a Olaf con il mio biglietto esteso. Lo prese, lo guardò e disse: "Tornerò".

Pensavo che mi stesse prendendo la mia ciambella, ma dopo 30 minuti ho iniziato a diventare sospettoso. Così ho chiesto al ragazzo dietro il bancone "Dov'è Olaf?". Ha detto "È andato a prendere soldi". "Cosa intendi?". "Prende nota in banca".

Eh ... così Olaf prese la nota che mi aveva dato la banca e tornò in banca per prelevare denaro dal mio conto. Dato che aveva la nota che la banca mi aveva dato, la banca sapeva che era il ragazzo di cui stavo parlando e, poiché ho parlato con la banca, sapevano che gli avrebbero dato solo $ 30.

Devo aver impiegato molto tempo a capirlo perché quando ho alzato lo sguardo, Olaf era finalmente in piedi davanti a me mi ha dato la mia ciambella. Prima di andarmene ho dovuto chiedere "Olaf, vendevi sempre ciambelle in questo modo?". "No, lo facevo diversamente."

Huh. Mentre tornavo alla macchina il mio telefono squillò. Non mi sono preoccupato di rispondere, probabilmente è stato il mio lavoro a chiamarmi per licenziarmi, il mio capo è un tale ***. Inoltre, sono stato sorpreso a pensare al processo che ho appena attraversato.

Voglio dire pensaci: sono stato in grado di lasciare che Olaf prelevasse $ 30 dal mio conto bancario senza dovergli fornire le informazioni del mio conto. E non dovevo preoccuparmi che avrebbe preso troppi soldi perché avevo già detto alla banca che gli era stato permesso di prendere solo $ 30. E la banca sapeva che era l'uomo giusto perché aveva il biglietto che mi avevano dato da dare a Olaf.

Ok, sicuramente preferirei dargli $ 30 dalla mia tasca. Ma ora che aveva quella nota, potevo solo dire alla banca di lasciargli prendere $ 30 ogni settimana, quindi potevo semplicemente presentarmi al forno e non dovevo più andare in banca. Potrei anche ordinare la ciambella per telefono se volessi.

Ovviamente non lo farei mai - quella ciambella era disgustosa.

Mi chiedo se questo approccio abbia applicazioni più ampie. Ha detto che questo era il suo secondo approccio, potrei chiamarlo Olaf 2.0. Comunque è meglio che torni a casa, devo iniziare a cercare un nuovo lavoro. Ma non prima di ottenere uno di quei frullati di fragole da quel nuovo posto dall'altra parte della città, ho bisogno di qualcosa per lavare via il sapore di quella ciambella.

— Luis Perez
fonte

41

Bene, in pratica Olaf dovrebbe essere in grado di prendere $ 30 dal tuo account ogni volta che vuole, anche se non ordini una ciambella. È interessante notare che questo è l'obiettivo principale nei veri scenari oauth2.0 :) Questa è sicuramente un'ottima risposta, ma chiunque stia leggendo questo si prega di andare all'essenziale che Paolo ha menzionato nel suo commento della domanda ( gist.github.com/mziwisky/ 10079157 ). Una buona lettura complementare per chiarire il concetto.

— Samiron,

4

Ottima risposta ma 2 punti da raccogliere: 1. Come ha sottolineato @Samiron, Olaf sarebbe in grado di prendere 30 $ ogni volta che lo desidera. 2. In uno scenario OAuth2.0 reale, Olaf non sarà in grado di servire la ciambella prima di prelevare denaro dalla banca. Mentre in questo esempio, avrebbe potuto conservare l'assegno e consegnare semplicemente a Luis la sua meritata ciambella. Quindi se modifichiamo l'esempio per autorizzare Olaf a ottenere un impasto da qualche terza parte che conosco, allora avrebbe più senso dato che Olaf dovrebbe ottenere l'impasto prima che inizi a cuocere la ciambella (supponendo che la ciambella solitaria Olaf era stato solo a scopo di visualizzazione!).

— Ticker23

4

ticker23, la storia della ciambella purtroppo batte la tua correzione tecnica - quando l'ho letta sono stata venduta sulla storia. È stato scritto da Homer Simpson.

— Shevy,

4

@Prageeth Olaf trasporta sempre la nota da e verso la banca in una scatola sicura che perde inchiostro se manomessa, ci vorrebbe molte vite per ripristinare la nota. La banca prende anche le impronte digitali dei clienti alla loro prima visita, se Olaf perde le dita in un incidente di cottura, dovrà chiedere a Luis di impostare nuovamente il bonifico, e la banca dovrà identificare Olaf con il suo tatuaggio di Breaking Bread la prossima volta .

— Chris,

11

Adoro le risposte carine tanto quanto la persona successiva, e quando la loro carineria aiuta a rendere la risposta più accessibile è fantastico ... ma alla fine della giornata Stack Overflow riguarda l'educazione delle persone, e questa storia carina non lo fa. Per capire anche l'analogia della ciambella devi già capire come funziona OAuth2, ma il punto centrale della risposta doveva essere quello di spiegarlo con precisione. Per favore, considera la modifica di questa (in alto) risposta per spiegare effettivamente i concetti, non solo per farli riferimento obliquamente alla fine ... anche se ciò comporta un costo di uno o due scherzi.

— Machineghost,

133

Sulla base di ciò che ho letto, ecco come funziona tutto:

Il flusso generale indicato nella domanda è corretto. Nel passaggio 2, l'utente X viene autenticato e autorizza anche l'accesso del sito A alle informazioni dell'utente X sul sito B. Nel passaggio 4, il sito restituisce il suo segreto al sito B, autenticandosi, nonché il codice di autorizzazione, indicando cosa sta chiedendo (token di accesso dell'utente X).

Nel complesso, OAuth 2 è in realtà un modello di sicurezza molto semplice e la crittografia non entra mai direttamente in gioco. Al contrario, sia il token segreto che quello di sicurezza sono essenzialmente password e il tutto è protetto solo dalla sicurezza della connessione https.

OAuth 2 non ha protezione contro gli attacchi replay del token di sicurezza o del segreto. Invece, si basa interamente sul fatto che il Sito B sia responsabile di questi elementi e non li lasci uscire, e che vengano inviati su https durante il trasporto (https proteggerà i parametri URL).

Lo scopo della fase del codice di autorizzazione è semplicemente la convenienza e il codice di autorizzazione non è particolarmente sensibile da solo. Fornisce un identificatore comune per il token di accesso dell'utente X per il sito A quando si chiede al sito B il token di accesso dell'utente X. Solo l'ID utente dell'utente X sul sito B non avrebbe funzionato, perché potrebbero esserci molti token di accesso eccezionali in attesa di essere distribuiti contemporaneamente a siti diversi.

— William Jones
fonte

28

Hai trascurato un'importante funzione del codice di autorizzazione. Perché non restituire immediatamente il token di aggiornamento (ciò che si chiama token di sicurezza) invece di avere il passaggio aggiuntivo di scambiare il codice di autorizzazione per esso? Perché l'acquisizione del token di aggiornamento consentirebbe attacchi di riproduzione, mentre il codice di autorizzazione può essere utilizzato solo una volta.

— Maurice Naftalin,

3

OK, @mauricen, ha un senso ... Ma l'attacco di replay non può avvenire altrettanto bene con il token di aggiornamento, poiché è quello che finisce per essere passato con ogni richiesta?

— Mr Mikkél,

15

Il codice di autorizzazione viene passato all'utente, quindi (ad esempio) potrebbe essere memorizzato come cookie (consultare stackoverflow.com/questions/4065657/… ). Il token di aggiornamento passa direttamente tra i due siti, quindi è molto meno vulnerabile.

— Maurice Naftalin,

Per curiosità, OAuth restituisce identificatori univoci che il programma può utilizzare? Ad esempio, attualmente mi affido all'indirizzo MAC per l'identificazione dell'utente, ma detto ciò, i MAC sono inaffidabili / facilmente falsificati / ecc. Potrei semplicemente eliminare il meccanismo di identificazione dell'indirizzo MAC e passare a OAuth se mi consente di identificare in modo univoco gli utenti.

— theGreenCabbage,

1

Si noti in questo diagramma: tools.ietf.org/html/rfc6749#section-4.1 che il "Segreto" non viene mostrato, ma solo l'identificatore del cliente (ID nella domanda). Perché il segreto è importante e perché non è incluso nella RFC? Inoltre nella domanda c'è anche lo stato locale che si consiglia di passare nella trasmissione iniziale dell'ID client (A) e il reindirizzamento al client insieme al codice di autorizzazione per la protezione da XSSF.

— David Williams,

104

OAuth è un protocollo con il quale un'app di 3 parti può accedere ai dati archiviati in un altro sito Web senza account e password. Per una definizione più ufficiale, consultare il Wiki o le specifiche.

Ecco una demo del caso d'uso:

Accedo a LinkedIn e voglio connettere alcuni amici che sono nei miei contatti di Gmail. LinkedIn lo supporta. Richiederà una risorsa sicura (il mio elenco di contatti di Gmail) da Gmail. Quindi faccio clic su questo pulsante:
Viene visualizzata una pagina Web che mostra la pagina di accesso di Gmail, quando inserisco il mio account e la mia password:
Gmail mostra quindi una pagina di consenso in cui faccio clic su "Accetta":
Ora LinkedIn può accedere ai miei contatti in Gmail:

Di seguito è riportato un diagramma di flusso dell'esempio sopra:

Aggiungi connessione

Passaggio 1: LinkedIn richiede un token dal server di autorizzazione di Gmail.

Passaggio 2: il server di autorizzazione di Gmail autentica il proprietario della risorsa e mostra all'utente la pagina di consenso. (l'utente deve accedere a Gmail se non ha già effettuato l'accesso)

Passaggio 3: l'utente concede la richiesta di LinkedIn per accedere ai dati di Gmail.

Passaggio 4: il server di autorizzazione Gmail risponde con un token di accesso.

Passaggio 5: LinkedIn chiama l'API di Gmail con questo token di accesso.

Passaggio 6: il server di risorse Gmail restituisce i contatti se il token di accesso è valido. (Il token verrà verificato dal server delle risorse di Gmail)

Puoi ottenere di più dai dettagli su OAuth qui .

— Owen Cao
fonte

Tutte le tue immagini sono scomparse. Hai qualche possibilità di caricarli su stack.imgur?

— ChrisF

1

Come può essere corretto? Questo processo non è avviato dall'utente seduto di fronte al browser, non da LinkedIn. Ma lo hai come passaggio 3. Questo è quello che non capisco.

— Matt,

17

La spiegazione più semplice Grazie, non comprerò mai più ciambelle

— OverCoder il

Il quarto passaggio di linkedin ritorna con un token di autorizzazione. Questo deve essere fornito nel 5 ° passaggio, dove avremo un token di accesso e un token di aggiornamento che potrebbero essere utilizzati ulteriormente per le risorse protette.

— amesh

@amesh Grazie, hai ragione, questo è il flusso del codice di autorizzazione, qui ho appena affermato in modo semplificato per mostrare l'idea di base di OAuth 2.

— Owen Cao

24

Figura 1, sollevata da RFC6750 :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

— 8bitjunkie
fonte

13

Ecco come funziona Oauth 2.0, ben spiegato in questo articolo

— Suraj
fonte

Puoi descrivere OAUTH2 in termini di non utilizzo di Facebook o di terze parti ma se usi chiavi segrete e token TOTP con l'app del telefono per proteggere l'app Web?

— Al Grant,

Facebook è il server di autorizzazione in questo esempio che emette token di accesso a qualsiasi client in modo che possano accedere alle API di Facebook. Se si desidera proteggere le API, è necessario implementare il proprio server di autorizzazione. Quindi decidi quale tipo di concessione vuoi utilizzare per ottenere il token di accesso. dimmi cosa vuoi esattamente? spieghero.

— Suraj,

Sto cercando di impostare con la sicurezza di avvio di primavera. Il client (telefono) e webapp si scambiano il segreto al momento della registrazione, quindi utilizzare Google Authenticator per generare codice basato su tempo / segreto da inserire durante l'accesso oltre alla password.

— Al Grant,

il mio ultimo commento ti illumina più? Vedi il mio profilo per informazioni su Twitter

— Al Grant,

puoi ottenere l'ID cliente e il segreto al momento della registrazione. Quindi, effettua una richiesta di accesso con ID client al tuo webapp (server di autorizzazione). l'app Web convalida l'ID client e invia l'OTP al telefono. Telefono effettua un'altra richiesta con webapp segreta a webapp per scambiare OTP con token di accesso. telefono usa questo token accss per accedere alle risorse protette su webapp. Penso che questo sarebbe il flusso Oauth2 per lo scenario dato. fammi sapere se ti aiuta.

— Suraj,

10

Questo è un gioiello:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Riepilogo molto breve:

OAuth definisce quattro ruoli:

Proprietario della risorsa
Cliente
Server di risorse
Server di autorizzazione

Tu (proprietario della risorsa) hai un telefono cellulare. Hai diversi account di posta elettronica, ma desideri tutti i tuoi account di posta elettronica in un'unica app, quindi non è necessario continuare a cambiare. Quindi il tuo GMail (client) richiede l'accesso (tramite il server di autorizzazione di Yahoo) alle tue e-mail di Yahoo (Resource Server) in modo da poter leggere entrambe le e-mail sulla tua applicazione GMail.

Il motivo per cui esiste OAuth è perché non è sicuro che GMail memorizzi il nome utente e la password di Yahoo.

— Belfield
fonte

8

L'altra risposta è molto dettagliata e affronta la maggior parte delle domande sollevate dal PO.

Per elaborare e in particolare rispondere alla domanda del PO di "In che modo OAuth 2 protegge da cose come gli attacchi replay usando il token di sicurezza?", Ci sono due protezioni aggiuntive nelle raccomandazioni ufficiali per l' implementazione OAuth 2:

1) I token avranno generalmente un breve periodo di scadenza ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

Un breve periodo di scadenza per i token è un mezzo di protezione contro le seguenti minacce:

replay...

2) Quando il token viene utilizzato dal sito A, la raccomandazione è che non verrà presentato come parametro URL ma nel campo dell'intestazione della richiesta di autorizzazione ( http://tools.ietf.org/html/rfc6750 ):

I client DOVREBBERO effettuare richieste autenticate con un token di connessione utilizzando il campo di intestazione della richiesta "Autorizzazione" con lo schema di autorizzazione HTTP "Portatore". ...

Il metodo "application / x-www-form-urlencoded" NON DOVREBBE essere utilizzato tranne nei contesti applicativi in cui i browser partecipanti non hanno accesso al campo di intestazione della richiesta "Autorizzazione". ...

Il parametro di query URI ... è incluso per documentare l'uso corrente; il suo uso non è raccomandato a causa delle sue carenze di sicurezza

— Volere
fonte

3

Ecco forse la spiegazione più semplice di come funziona OAuth2 per tutti e 4 i tipi di concessione, ovvero 4 diversi flussi in cui l'app può acquisire il token di accesso.

Somiglianza

Tutti i flussi del tipo di sovvenzione sono composti da 2 parti:

Ottieni token di accesso
Usa token di accesso

La seconda parte "usa token di accesso" è la stessa per tutti i flussi

Differenza

La prima parte del flusso "Ottieni token di accesso" per ciascun tipo di sovvenzione varia.

Tuttavia, in generale la parte "Ottieni token di accesso" può essere riassunta in 5 passaggi:

Pre-registra la tua app (client) con il provider OAuth, ad esempio Twitter, ecc. Per ottenere l'ID / segreto del client
Crea un pulsante di accesso social con ID client e ambiti / autorizzazioni richiesti sulla tua pagina in modo che quando l'utente cliccato viene reindirizzato al provider OAuth per essere autenticato
Il provider OAuth richiede all'utente di concedere l'autorizzazione alla tua app (client)
Codice di emissione del provider OAuth
L'app (client) acquisisce il token di accesso

Ecco un diagramma affiancato che confronta il modo in cui ciascun flusso di tipo di sovvenzione è diverso in base ai 5 passaggi.

Questo diagramma è tratto da https://blog.oauth.io/introduction-oauth2-flow-diagrams/

Ognuno ha diversi livelli di difficoltà di implementazione, sicurezza e casi d'uso. A seconda delle esigenze e della situazione, dovrai utilizzarne una. Quale usare?

Credenziali del cliente : se l'app serve un solo utente

Crendenziale della password del proprietario della risorsa : deve essere utilizzato solo come ultima risorsa in quanto l'utente deve consegnare le proprie credenziali all'app, il che significa che l'app può fare tutto ciò che l'utente può

codice di autorizzazione : il modo migliore per ottenere l'autorizzazione dell'utente

Implicito : se l'app è un'app mobile o a pagina singola

C'è più spiegazione della scelta qui: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/

— nethsix
fonte