OAuth 2.0: vantaggi e casi d'uso - perché?

Qualcuno potrebbe spiegare cosa c'è di buono in OAuth2 e perché dovremmo implementarlo? Lo chiedo perché sono un po 'confuso al riguardo - ecco i miei pensieri attuali:

Le richieste di OAuth1 (più precisamente HMAC) sembrano logiche, facili da capire, facili da sviluppare e molto, molto sicure.

OAuth2, invece, porta richieste di autorizzazione, token di accesso e token di aggiornamento, e devi fare 3 richieste all'inizio di una sessione per ottenere i dati che stai cercando. E anche allora, una delle tue richieste finirà per fallire alla scadenza del token.

E per ottenere un altro token di accesso, si utilizza un token di aggiornamento che è stato passato contemporaneamente al token di accesso. Ciò rende il token di accesso inutile dal punto di vista della sicurezza?

Inoltre, come ha mostrato di recente / r / netsec, SSL non è del tutto sicuro, quindi la spinta a ottenere tutto su TLS / SSL invece di un HMAC sicuro mi confonde.

OAuth sostiene che non si tratta di sicurezza al 100%, ma di pubblicarlo e completarlo. Non sembra esattamente promettente dal punto di vista di un fornitore. Riesco a vedere cosa sta tentando di realizzare la bozza quando menziona i 6 diversi flussi, ma non si adatta perfettamente alla mia testa.

Penso che potrebbe essere più difficile lottare per capire i suoi benefici e ragionamenti piuttosto che non amarlo, quindi questo potrebbe essere un po 'un attacco ingiustificato, e mi dispiace se questo potrebbe sembrare un furto.

Sfondo: ho scritto stack di client e server per OAuth 1.0a e 2.0.

Sia OAuth 1.0a che 2.0 supportano l' autenticazione a due gambe , in cui un server è sicuro dell'identità di un utente, e l' autenticazione a tre gambe , in cui un server è assicurato da un fornitore di contenuti dell'identità dell'utente. L'autenticazione a tre gambe è il punto in cui entrano in gioco le richieste di autorizzazione e i token di accesso, ed è importante notare che anche OAuth 1 ne ha.

Quello complesso: autenticazione a tre zampe

Un punto principale delle specifiche di OAuth è che un fornitore di contenuti (ad es. Facebook, Twitter, ecc.) Assicuri a un server (ad es. Un'app Web che desidera parlare con il fornitore di contenuti per conto del cliente) che il cliente ha qualche identità . Ciò che offre l'autenticazione a tre zampe è la possibilità di farlo senza che il client o il server debbano mai conoscere i dettagli di tale identità (ad esempio nome utente e password).

Senza (?) Approfondire troppo i dettagli di OAuth:

1. Il client invia una richiesta di autorizzazione al server, che convalida che il client è un client legittimo del suo servizio.
2. Il server reindirizza il client al provider di contenuti per richiedere l'accesso alle sue risorse.
3. Il provider di contenuti convalida l'identità dell'utente e spesso richiede l'autorizzazione per accedere alle risorse.
4. Il provider di contenuti reindirizza il client al server, avvisandolo di esito positivo o negativo. Questa richiesta include un codice di autorizzazione in caso di successo.
5. Il server invia una richiesta fuori banda al provider di contenuti e scambia il codice di autorizzazione con un token di accesso.

Il server può ora effettuare richieste al fornitore di contenuti per conto dell'utente passando il token di accesso.

Ogni scambio (client-> server, server-> provider di contenuti) include la convalida di un segreto condiviso, ma poiché OAuth 1 può essere eseguito su una connessione non crittografata, ogni convalida non può passare il segreto sul filo.

Questo è stato fatto, come hai notato, con HMAC. Il client utilizza il segreto che condivide con il server per firmare gli argomenti per la sua richiesta di autorizzazione. Il server accetta gli argomenti, li firma da solo con la chiave del client ed è in grado di vedere se si tratta di un client legittimo (nel passaggio 1 sopra).

Questa firma richiede che sia il client che il server siano d'accordo sull'ordine degli argomenti (quindi stanno firmando esattamente la stessa stringa), e una delle lamentele principali su OAuth 1 è che richiede sia il server che i client per ordinare e firmare in modo identico. Questo è un codice complicato e o è giusto o ottieni 401 Unauthorizedpoco aiuto. Ciò aumenta la barriera alla scrittura di un client.

Richiedendo l'esecuzione della richiesta di autorizzazione su SSL, OAuth 2.0 elimina la necessità di ordinare e firmare del tutto gli argomenti. Il client passa il suo segreto al server, che lo convalida direttamente.

Gli stessi requisiti sono presenti nella connessione server-> content provider e poiché si tratta di SSL che rimuove una barriera alla scrittura di un server che accede ai servizi OAuth.

Ciò rende le cose molto più semplici nei passaggi 1, 2 e 5 sopra.

Quindi a questo punto il nostro server ha un token di accesso permanente che è un nome utente / password equivalente per l'utente. Può inviare richieste al fornitore di contenuti per conto dell'utente passando tale token di accesso come parte della richiesta (come argomento della query, intestazione HTTP o dati del modulo POST).

Se il servizio di contenuti è accessibile solo tramite SSL, abbiamo finito. Se è disponibile tramite semplice HTTP, vorremmo proteggere in qualche modo quel token di accesso permanente. Chiunque annusa la connessione sarebbe in grado di accedere per sempre ai contenuti dell'utente.

Il modo risolto in OAuth 2 è con un token di aggiornamento . Il token di aggiornamento diventa l'equivalente della password permanente ed è sempre e solo trasmesso su SSL . Quando il server necessita dell'accesso al servizio di contenuti, scambia il token di aggiornamento con un token di accesso di breve durata. In questo modo tutti gli accessi HTTP sniffabili vengono effettuati con un token che scadrà. Google sta utilizzando una scadenza di 5 minuti sulle loro API OAuth 2.

Quindi, a parte i token di aggiornamento, OAuth 2 semplifica tutte le comunicazioni tra client, server e provider di contenuti. E i token di aggiornamento esistono solo per fornire sicurezza quando si accede al contenuto non crittografato.

Autenticazione a due gambe

A volte, tuttavia, un server deve solo controllare l'accesso al proprio contenuto. L'autenticazione a due gambe consente al client di autenticare l'utente direttamente con il server.

OAuth 2 standardizza alcune estensioni di OAuth 1 che erano ampiamente utilizzate. Quello che conosco meglio è stato introdotto da Twitter come xAuth . Puoi vederlo in OAuth 2 come credenziali della password del proprietario della risorsa .

In sostanza, se puoi fidarti del client con le credenziali dell'utente (nome utente e password), questi possono scambiarli direttamente con il fornitore di contenuti con un token di accesso. Ciò rende OAuth molto più utile nelle app mobili: con l'autenticazione a tre gambe, è necessario incorporare una vista HTTP per gestire il processo di autorizzazione con il server dei contenuti.

Con OAuth 1, questo non faceva parte dello standard ufficiale e richiedeva la stessa procedura di firma di tutte le altre richieste.

Ho appena implementato il lato server di OAuth 2 con le credenziali della password del proprietario della risorsa e, dal punto di vista del client, ottenere il token di accesso è diventato semplice: richiedere un token di accesso dal server, passando l'ID / segreto del client come intestazione di autorizzazione HTTP e il login / password dell'utente come dati del modulo.

Vantaggio: semplicità

Quindi dal punto di vista di un implementatore, i principali vantaggi che vedo in OAuth 2 sono nella complessità ridotta. Non richiede la procedura di firma della richiesta, che non è esattamente difficile ma è certamente complicata. Riduce notevolmente il lavoro richiesto per agire come cliente di un servizio, che è dove (nel moderno mondo mobile) si desidera ridurre al minimo il dolore. La ridotta complessità sul lato server-> content provider lo rende più scalabile nel data center.

E codifica nello standard alcune estensioni di OAuth 1.0a (come xAuth) che sono ora ampiamente utilizzate.

Innanzitutto, come chiaramente indicato nell'autenticazione OAuth

OAuth 2.0 non è un protocollo di autenticazione.

L'autenticazione nel contesto di un utente che accede a un'applicazione indica a un'applicazione chi è l'utente corrente e se sono presenti o meno. Un protocollo di autenticazione completo fornirà probabilmente anche una serie di attributi su questo utente, come un identificatore univoco, un indirizzo e-mail e come chiamarli quando l'applicazione dice "Buongiorno".

Tuttavia, OAuth non dice nulla all'applicazione. OAuth non dice assolutamente nulla sull'utente, né dice come l'utente ha dimostrato la sua presenza o anche se sono ancora lì. Per quanto riguarda un client OAuth, ha chiesto un token, ottenuto un token e infine utilizzato quel token per accedere ad alcune API. Non sa nulla di chi abbia autorizzato l'applicazione o se ci fosse addirittura un utente lì.

Esiste uno standard per l'autenticazione utente tramite OAuth: OpenID Connect, compatibile con OAuth2.

Il token ID OpenID Connect è un token Web JSON (JWT) firmato che viene assegnato all'applicazione client insieme al normale token di accesso OAuth. Il token ID contiene una serie di attestazioni relative alla sessione di autenticazione, tra cui un identificatore per l'utente (sub), l'identificatore per il provider di identità che ha emesso il token (iss) e l'identificatore del client per cui è stato creato questo token ( AUD).

In Go, puoi guardare coreos / dex, un OpenID Connect Identity (OIDC) e un provider OAuth 2.0 con connettore innestabile.

Risposta da questo post vonc

Risponderei a questa domanda in modo leggermente diverso, e sarò molto preciso e breve, principalmente perché @Peter T ha risposto a tutto.

Il vantaggio principale che vedo da questo standard è il rispetto di due principi:

1. Separazione degli interessi.
2. Disaccoppiamento dell'autenticazione dall'applicazione Web, che di solito serve al business.

Facendo così,

1. È possibile implementare un'alternativa a Single SignOn: se si dispone di più applicazioni che si fidano di una STS. Voglio dire, un nome utente per tutte le applicazioni.
2. È possibile abilitare l'applicazione Web (il client) per accedere alle risorse che appartengono all'utente e non appartengono all'applicazione web (il client).
3. Puoi affidare il processo di autenticazione a terzi di cui ti fidi e non preoccuparti mai della convalida dell'autenticità dell'utente.