OAuth 2.0 ha più flussi di lavoro. Ho alcune domande riguardo ai due.

1. Flusso del codice di autorizzazione : l'utente accede dall'app client, il server delle autorizzazioni restituisce un codice di autorizzazione all'app. L'app scambia quindi il codice di autorizzazione con il token di accesso.
2. Flusso di concessione implicito : l'utente accede dall'app client, il server delle autorizzazioni emette direttamente un token di accesso all'app client.

Qual è la differenza tra i due approcci in termini di sicurezza? Quale è più sicuro e perché?

Non vedo un motivo per cui un passaggio aggiuntivo (scambio codice di autorizzazione per token) viene aggiunto in un flusso di lavoro quando il server può emettere direttamente un token di accesso.

Diversi siti Web affermano che il flusso del codice di autorizzazione viene utilizzato quando l'app client può proteggere le credenziali. Perché?

Il access_tokenè ciò che è necessario chiamare una risorsa protetta (un'API). Nel flusso del codice di autorizzazione ci sono 2 passaggi per ottenerlo:

1. L'utente deve autenticarsi e restituire un messaggio codeal consumatore API (chiamato "Client").
2. Il "client" dell'API (di solito il tuo server Web) scambia l' codeottenuto in # 1 con un access_token, autenticandosi con un client_ideclient_secret
3. Quindi può chiamare l'API con il access_token.

Quindi, c'è un doppio controllo: l'utente che possiede le risorse emerse attraverso un'API e il client che utilizza l'API (ad esempio un'app Web). Entrambi sono convalidati per consentire l'accesso. Nota qui la natura di "autorizzazione" di OAuth: l'utente concede l'accesso alla sua risorsa (tramite l' codeautenticazione restituita dopo) a un'app, l'app viene acquisita access_tokene chiama per conto dell'utente.

Nel flusso implicito, il passaggio 2 viene omesso. Quindi, dopo l'autenticazione dell'utente, access_tokenviene restituito direttamente un elemento che è possibile utilizzare per accedere alla risorsa. L'API non sa chi sta chiamando quell'API. Chiunque abbia la access_tokenlattina, mentre nell'esempio precedente solo l'app Web lo farebbe (i suoi interni normalmente non sono accessibili a nessuno).

Il flusso implicito viene solitamente utilizzato negli scenari in cui è archiviato client ide client secretnon è consigliato (un dispositivo, ad esempio, sebbene molti lo facciano comunque). Questo è ciò che significa il disclaimer. Le persone hanno accesso al codice client e quindi potrebbero ottenere le credenziali e fingere di diventare client risorse. Nel flusso implicito tutti i dati sono volatili e non c'è nulla memorizzato nell'app.

Aggiungerò qualcosa qui che non credo sia chiarito nelle risposte sopra:

• Il flusso di codice di autorizzazione consente al token di accesso finale di non raggiungere mai e di non essere mai archiviato sulla macchina con il browser / l'app . Il codice di autorizzazione temporaneo viene fornito alla macchina con il browser / l'app, che viene quindi inviato a un server. Il server può quindi scambiarlo con un token di accesso completo e avere accesso alle API, ecc. L'utente con il browser ottiene l'accesso all'API solo attraverso il server con il token.
• Il flusso implicito può coinvolgere solo due parti e il token di accesso finale viene archiviato sul client con il browser / l'app. Se questo browser / app è compromesso, lo è anche il loro token di autenticazione che potrebbe essere pericoloso.

tl; dr non utilizzare il flusso implicita se non vi fidate della macchina agli utenti di tenere gettoni, ma si fa confidare il proprio server.

La differenza tra entrambi è che:

1. Nel flusso implicito, il token viene restituito direttamente tramite URL di reindirizzamento con il segno "#" e questo viene utilizzato principalmente nei client javascript o nelle applicazioni mobili che non dispongono di un lato server e il client non deve fornire il suo segreto in alcune implementazioni .

2. Nel flusso del codice di autorizzazione, il codice viene restituito con "?" per essere leggibile dal lato server, il lato server deve fornire questa volta il segreto client all'URL token per ottenere il token come oggetto json dal server di autorizzazione. Viene utilizzato nel caso in cui si disponga di un server delle applicazioni in grado di gestire questo e archiviare il token utente con il proprio profilo sul proprio sistema e utilizzato principalmente per le comuni applicazioni mobili.

quindi dipende dalla natura dell'applicazione client, quale altro "Codice di autorizzazione" sicuro in quanto viene richiesto il segreto sul client e il token può essere inviato tra il server di autorizzazione e l'applicazione client su una connessione molto sicura, e il fornitore di autorizzazione può limitare alcuni client a utilizzare solo "Codice di autorizzazione" e non consentire Implicito

La concessione implicita è simile alla concessione del codice di autorizzazione con due differenze distinte.

È destinato all'uso per client basati su user-agent (ad es. App Web a pagina singola) che non possono mantenere un client segreto perché tutto il codice dell'applicazione e lo spazio di archiviazione sono facilmente accessibili.

In secondo luogo, invece del server di autorizzazione che restituisce un codice di autorizzazione che viene scambiato con un token di accesso, il server di autorizzazione restituisce un token di accesso.

Per i dettagli, consultare http://oauth2.thephpleague.com/authorization-server/which-grant/

Flusso implicito

vantaggi

• Più semplice da implementare

svantaggi

• Token di accesso visibili al browser
• L'origine dei token di accesso non può essere determinata
• I token di accesso non possono scadere (secondo le norme di Google)

Flusso del codice di autorizzazione

vantaggi

• Più sicuro
• I token di accesso e i token di aggiornamento possono essere creati solo se è noto un segreto condiviso
• Può essere migliorato con nuove funzionalità di sicurezza e UX quando saranno disponibili

svantaggi

• È necessario implementare più endpoint di autenticazione

Citazione: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

Consentitemi di riassumere i punti che ho appreso dalle risposte di cui sopra e aggiungere alcune delle mie comprensioni.

Flusso del codice di autorizzazione !!!

• Se si dispone di un server di applicazioni Web che funge da client OAuth
• Se si desidera avere un accesso di lunga durata
• Se si desidera avere accesso offline ai dati
• quando sei responsabile per le chiamate API che l'app effettua
• Se non vuoi perdere il tuo token OAuth
• Se non si desidera che l'applicazione esegua il flusso di autorizzazioni ogni volta che deve accedere ai dati. NOTA: il flusso di concessione implicita non intrattiene il token di aggiornamento, quindi se il server di autorizzazione scade regolarmente i token di accesso, l'applicazione dovrà eseguire il flusso di autorizzazione ogni volta che necessita dell'accesso.

Flusso di concessione implicito !!!

• Quando non si dispone di Web Application Server per fungere da client OAuth
• Se non hai bisogno di un accesso di lunga durata, cioè è richiesto solo un accesso temporaneo ai dati.
• Se ti fidi del browser su cui è in esecuzione l'app e c'è una preoccupazione limitata che il token di accesso perderà agli utenti non attendibili.

Quale è più sicuro e perché?

Entrambi sono sicuri, dipende dall'ambiente in cui lo si utilizza.

Non vedo un motivo per cui un passaggio aggiuntivo (scambio codice di autorizzazione per token) viene aggiunto in un flusso di lavoro quando il server può emettere direttamente un token di accesso.

È semplice. Il tuo client non è sicuro. Vediamolo in dettaglio.

Considerare che si sta sviluppando un'applicazione contro Instagram API, quindi registrare la tua APP con Instagrame definire quale API'sè necessario. Instagramti fornirà client_ideclient_secrect

Sul tuo sito web hai impostato un link che dice. "Vieni e usa la mia applicazione". Facendo clic su questo, l'applicazione Web dovrebbe effettuare due chiamate a Instagram API.

Firstinvia una richiesta Instagram Authentication Servercon i parametri seguenti.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

Non inviiclient_secret , non puoi fidarti del client (l'utente e il suo browser che tentano di utilizzare la tua applicazione). Il client può vedere lo script url o java e trovarlo client_secrectfacilmente. Questo è il motivo per cui hai bisogno di un altro passo.

Ricevi un codee state. Il codequi è temporarye non viene salvato da nessuna parte.

Quindi si effettua una secondchiamata a Instagram API(dal proprio server)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Poiché la chiamata viene effettuata dal nostro server, possiamo tranquillamente utilizzare client_secret(che mostra come siamo) con codecui l'utente ha concesso l' client_idutilizzo della risorsa.

In risposta avremo access_token

Dal punto di vista pratico (cosa ho capito), la ragione principale per avere un flusso di codice Authz è:

1. Supporto per token di aggiornamento (accesso a lungo termine da parte di app per conto dell'utente), non supportato in modo implicito: consultare: https://tools.ietf.org/html/rfc6749#section-4.2
2. Supporto per la pagina di consenso che è un luogo in cui il proprietario delle risorse può controllare quale accesso fornire (tipo di pagina di autorizzazioni / autorizzazioni che vedi in google). Lo stesso non è implicito. Vedere la sezione: https://tools.ietf.org/html/rfc6749#section-4.1 , punto (B)

"Il server di autorizzazione autentica il proprietario della risorsa (tramite l'agente utente) e stabilisce se il proprietario della risorsa concede o rifiuta la richiesta di accesso del client"

Inoltre, utilizzando i token di aggiornamento, le app possono ottenere l'accesso a lungo termine ai dati degli utenti.

Sembrano esserci due punti chiave, non discussi finora, che spiegano perché la deviazione nel tipo di concessione del codice di autorizzazione aggiunge sicurezza.

Breve storia : il tipo di concessione del codice di autorizzazione mantiene le informazioni sensibili dalla cronologia del browser e la trasmissione del token dipende solo dalla protezione HTTPS del server di autorizzazione.

Versione più lunga:

Di seguito, seguirò la terminologia OAuth 2 definita nella RFC (è una lettura veloce): server delle risorse , client , server delle autorizzazioni , proprietario delle risorse .

Immagina di volere che un'app di terze parti (= client) acceda a determinati dati del tuo account Google (= server delle risorse). Supponiamo che Google usi OAuth 2. Sei il proprietario delle risorse per l'account Google, ma in questo momento gestisci l'app di terze parti.

Innanzitutto, il client apre un browser per inviarti all'URL sicuro del server di autorizzazione di Google. Quindi approvi la richiesta di accesso e il server di autorizzazione ti rimanda all'URL di reindirizzamento precedentemente indicato dal client, con il codice di autorizzazione nella stringa di query. Ora per i due punti chiave:

1. L'URL di questo reindirizzamento finisce nella cronologia del browser . Quindi non vogliamo un token di accesso utilizzabile direttamente e di lunga durata qui. Il codice di autorizzazione di breve durata è meno pericoloso nella storia. Si noti che il tipo di concessione implicita fa mettere il gettone nella storia.
2. La sicurezza di questo reindirizzamento dipende dal certificato HTTPS del client , non dal certificato di Google. Quindi otteniamo la sicurezza della trasmissione del client come un vettore di attacco aggiuntivo (affinché ciò sia inevitabile, il client deve essere non JavaScript. In caso contrario, potremmo trasmettere il codice di autorizzazione tramite l'URL del frammento, dove il codice non passerebbe attraverso la rete. Questo può essere il motivo per cui implicita rilascio, che fa utilizzare un URL frammento, usato per essere raccomandato per i clienti JavaScript, anche se questo non è più così.)

Con il tipo di concessione del codice di autorizzazione, il token viene infine ottenuto da una chiamata dal client al server di autorizzazione, in cui la sicurezza della trasmissione dipende solo dal server di autorizzazione , non dal client.