OAuth2 JWT Firma con OAuth2 Application Secret Key

4

Estratto (mi dispiace, questo è un boccone):

Vorrei facilitare l'autorizzazione back-to-system tramite OAuth2 e JWT facendo uso del parametro 'aud' di JWT per specificare una risorsa specifica per un'applicazione (tramite una richiesta di concessione dell'autorizzazione JWT al server di autorizzazione) e quindi il server di autorizzazione firma (o crittografa) il JWT con la chiave segreta OAuth2 dell'applicazione OAuth2 registrata che contiene la risorsa specificata dal parametro 'aud' in modo che il server di risorse per il quale è stato richiesto un token possa convalidare il token con la sua chiave segreta dell'applicazione OAuth2.

Riepilogo:

Ho una domanda relativa all'autorizzazione da sistema a sistema back-end con OAuth2 e JWT.

  • Dato un server di risorse RA
  • E un RB del server di risorse
  • E un server di autorizzazione AS
  • E RA e RB sono registrati applicazioni OAuth2 con AS

Vogliamo utilizzare la specifica OAuth2 con JWT per ottenere quanto segue:

  1. RA richiede un JWT da AS
  2. AS risponde a RA con un JWT
  3. RA richiede una risorsa da RB utilizzando il JWT
  4. RB risponde a RA con i dati delle risorse (senza dover chiamare AS)

Il problema:

L'obiettivo è che RB abbia la capacità di convalidare il JWT indipendentemente da AS. Detto questo, RB deve avere un modo per convalidare il JWT che è stato inviato nella richiesta da RA. Dato che AS ha rilasciato il JWT inviato da RA, AS e RB DEVONO avere un segreto condiviso.

Sarebbe una cattiva prassi di sicurezza avere un segreto condiviso tra tutti i server di risorse e il server di autorizzazione per l'esplicito scopo di utilizzarlo per la firma e / o la crittografia JWT. Questa soluzione avrebbe messo a punto la specifica OAuth2 (Delega di autorizzazione) che ha cercato di attenuare scrupolosamente i problemi di sicurezza derivanti da chiavi simmetriche ampiamente distribuite, ecc.

Proposta:

La mia proposta approssimativa è di risolvere questo problema è la seguente:

  1. RA richiede un JWT da AS utilizzando la concessione dell'autorizzazione JWT e specifica una risorsa nell'API RB nel parametro "aud" ( link vedi numero" 3. ")
  2. AS Risponde con un JWT firmato / crittografato con la chiave segreta dell'applicazione RB (AS può identificare quale applicazione segreta utilizzare in base all'URI del parametro 'aud')
  3. RA richiede una risorsa in RB utilizzando il JWT
  4. RB convalida il JWT firmato / crittografato utilizzando la chiave segreta OAuth2

La mia domanda:

La proposta ha senso qui? Esiste un'implementazione molto più semplice che potrebbe comunque raggiungere il mio obiettivo e rimanere all'interno delle specifiche OAuth2? È un uso improprio del parametro JWT 'aud'?

Grazie mille per aver letto questo e per il tuo aiuto.

    
posta Will Sulzer 05.01.2016 - 21:00
fonte

1 risposta

1

Sembra un caso in cui sarebbe utile il nuovo servizio di introspezione aggiunto a OAuth2 ( link ). Permette al tuo RB di validare il token di accesso (il JWT) inoltrato da RA contro l'AS.

Ciò interrompe la tua richiesta che non c'è comunicazione tra RB e AS. Ma questo non dovrebbe essere un problema, poiché questi servizi si fidano già l'uno dell'altro. Non sono presenti chiavi simmetriche globalmente o trust impliciti tra RA e RB coinvolti.

Interpola nel tuo stream:

  1. RA richiede un JWT da AS
  2. AS risponde a RA con un JWT
  3. RA richiede una risorsa da RB utilizzando il JWT
  4. RB convalida il JWT contro il servizio AS / introspection
  5. RB risponde a RA con i dati delle risorse
risposta data 06.01.2016 - 06:46
fonte

Leggi altre domande sui tag