Qual è il vantaggio di OAuth "flusso di codice monouso (autenticazione ibrida)"?

Question

Qual è il vantaggio di OAuth "flusso di codice monouso (autenticazione ibrida)"?

#1 da (3 voti)

3

Con riferimento al omniauth-google-oauth2 gem che descrive ciò che chiama "One-Time Code Flow (Hybrid Authentication)" come tale:

This hybrid authentication flow has significant functional and security advantages over a pure server-side or pure client-side flow.

Il readme continua quindi a descrivere la meccanica del flusso stesso e termina con:

This flow is immune to replay attacks, and conveys no useful information to a man in the middle.

Non sono stato in grado di trovare alcuna spiegazione sul web in merito a perché è così, o in che modo è superiore all'autenticazione OAuth 2.0 puramente sul lato server. La maggior parte del materiale sembra parlare solo della meccanica di varie strategie OAuth.

Più in particolare, ciò che non capisco è questo: se è lo stesso flusso di informazioni tra client / server / provider di autenticazione o solo server / auth provider, allora la strategia non è altrettanto suscettibile agli attacchi?

oauth

posta JonoB 28.07.2016 - 01:25

fonte

1 risposta

Leggi altre domande sui tag oauth

Offuscamento dei pacchetti di rete Memorizzazione password Hash in chiaro

score 3 · Accepted Answer

Così come hai descritto, una "Hybrid Authentication" è una soluzione intermedia tra pura autenticazione lato server e pura client-side. Ciò significa che tutte le attività necessarie per ottenere un'autenticazione completa avranno bisogno sia del server che del client.

Ecco come si verifica un'autenticazione lato server:

fai clic sul pulsante di accesso
ottieni il dialogo di consenso per chiedere il tuo permesso
devi specificare un (reindirizzamento URI)
ottieni 2 cose:

1- get reindirizzato all'URI di reindirizzamento

2- ottieni un codice aggiunto all'URI di reindirizzamento (token ID utente)
sostituisci il (token ID utente < - > Token di accesso, token di aggiornamento) dal server di autorizzazione di google #NOT SECURE

Ecco come si verifica un flusso di codice monouso:

fai clic sul pulsante Accedi (una variabile di stato viene creata in background)
ottieni il dialogo di consenso per chiedere il tuo permesso
devi specificare un (reindirizzamento URI)
ottieni 2 cose:

1- viene reindirizzato all'URI di reindirizzamento (la variabile #State viene reindirizzata con te)

2- ottieni un codice aggiunto all'URI di reindirizzamento (token ID utente)
ti scambi quel codice con il tuo server #VERY SECURE (Consegnate la variabile di stato code + e il server confronta quella variabile di stato con quella che ha già) #NO CSRF
server scambia il (token ID utente < - > Token di accesso, token di aggiornamento) dal server di autorizzazione google

Quindi questo scambio qui è immune ad entrambi gli attacchi di replay e non fornisce un MITM con alcuna informazione utile, perché anche se l'attaccante ha intercettato qualsiasi pacchetto, dovrà comunque ottenere quella variabile di stato ed elaborare il codice aggiunto attraverso il server. In contrasto con la pura implementazione lato server dove tutto ciò che l'utente malintenzionato deve fare è inviare il codice a google in cambio con il token di accesso e il token di aggiornamento.

Ecco anche una foto per mettere le cose in prospettiva, sperando che la differenza ora sia più chiara.