Come funziona Oauth a 2 vie in OAuth 2.0?

Question

In OAuth 1.0, 2-legged è abbastanza semplice: basta inviare la richiesta come al solito e omettere l'intestazione access_token.

Le cose sembrano essere cambiate in OAuth 2.0 (drasticamente, come ho scoperto oggi :)). In OAuth 2.0, la richiesta non ha più intestazioni come il nonce, chiave dei consumatori, timestamp ecc Questo è solo sostituito dal seguente:

Authorization: OAuth ya29.4fgasdfafasdfdsaf3waffghfhfgh 

Capisco come 3 autorizzazioni zampe lavorano in OAuth 2.0 e flussi l'applicazione. Ma come funziona 2-legged in 2.0? È possibile progettare un'API in grado di supportare OAuth 2.0 a 2 e 3 vie?

Sono stato alla ricerca di informazioni su questo, ma ho trovato un sacco di cose su 2-gambe per 1.0 e quasi nulla per 2.0.

Answer 1

Dopo molte ricerche, ho scoperto che il tipo di sovvenzione client_credentials è per questo scenario. Una volta inserito questo termine in google, puoi trovare un sacco di risorse molto utili.

Questo è il flusso normale per OAuth 3 zampe 2.0 (vogliamo che l'utente per accedere):

Supponiamo di avere i seguenti punti finali nella nostra app per l'autenticazione:

/oauth/auth 

/oauth/token 

Normalmente (per codice di autorizzazione di sovvenzione), abbiamo indirizzare l'utente a /oauth/auth?state=blah&client_id=myid&redirecturl=mysite.com/blah

Poi dopo l'autenticazione, l'utente viene reindirizzato a mysite.com/blah?code=somecode

Otteniamo quindi somecode e lo scambiamo per un token utilizzando /oauth/token?code=somecode&client_id=myid&client_secret=mysecret

Possiamo quindi utilizzare il token per effettuare chiamate.

---

Questo è il flusso domanda di client_credentials per implementare 2 zampe OAuth 2.0, che è decisamente più semplice:

• In questo approccio, non abbiamo bisogno di effettuare alcuna autenticazione.

• Abbiamo semplicemente post per /oauth/token con i seguenti dati modulo:

  grant_type=client_credentials&scope=view_friends 
  

Si noti che la portata è opzionale. L'endpoint quindi restituisce direttamente un token di accesso da utilizzare (non viene fornito alcun token di aggiornamento). Poiché non viene fornito alcun token di aggiornamento, quando il token scade, sarà necessario riautenticarlo e richiederne uno nuovo.

Questo porta alle seguenti avvertenze:

• utilizzare questo solo per (molto molto) applicazioni attendibili come le applicazioni interne.
• È necessario il dispositivo a modo tuo per l'autenticazione. Ad esempio, lo RFC's example utilizza l'autenticazione di base.

Un'altra soluzione è utilizzare JWT (token Web JSON) come lo google OAuth API. È un processo molto complicato, ma esistono numerose librerie per generare il tuo JWT. È quindi inviare i seguenti dati del modulo (URL codificato, naturalmente):

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=generated_jwt 

Questo viene inviato alle /oauth/token per ottenere il token.

---

Per quanto riguarda la domanda di se è possibile creare un'API che supporta 2 zampe e 3 gambe OAuth 2.0, Sì, è possibile.

Quindi l'endpoint /auth viene utilizzato solo quando gli utenti devono autenticarsi con il servizio.

Nel /token endpoint, semplicemente controllare il valore di grant_type nei parametri GET per urn:ietf:params:oauth:grant-type:jwt-bearer se si utilizza JWT o client_credentials per client_credentials.

Si noti che durante la generazione di client_id e client_secret da fornire all'utente, se si supporta più grant_types, assicurarsi di disporre di una colonna del database per memorizzare il tipo di tipo di concessione per cui ID e segreto sono stati generati. Se è necessario disporre di più tipi di sovvenzione per utente, generare un diverso insieme di credenziali per ciascun tipo di sovvenzione.

Answer 2

È anche possibile verificare l'implementazione di Google di 2-legged OAuth2 (credo che questa documentazione sia stata pubblicata solo di recente).

Lo Google Drive SDK delegation docs dovrebbe anche aiutare a comprendere l'implementazione OAuth2 a due vie di Google.