Aggiorna i token in OAuth2 con JWT

3

Sto cercando di implementare il flusso del proprietario delle risorse OAuth2. Il mio server di autorizzazione genera correttamente token web JSON, quindi il prossimo passo è implementare i token di aggiornamento per la mia applicazione web.

Tutto ciò che ho letto spiega che quando si richiede un token di accesso dal proprio server di autorizzazione si include l'URL del server di risorse come client_id . Questo viene quindi inserito in una richiesta di aud sul tuo JWT. È corretto?

Se è così, il mio problema sorge quando provo a implementare token di aggiornamento. I token di aggiornamento vengono emessi su base client, in modo che il campo client_id ora debba identificare il client e non l'URL del server di risorse. In questo caso, il mio server di autorizzazione ora non sa a chi assegnare il token, quindi non sa cosa aggiungere nella rivendicazione aud all'interno del JWT.

Sto cercando qualche consiglio sull'approccio migliore per risolvere questo problema in relazione alle specifiche OAuth2, non sembra esserci una risposta concreta là fuori per questo problema quando si mischiano OAuth2 e JWT.

Qualcuno ha qualche idea?

Il mio flusso attuale ha questo aspetto:

  1. Il client invia una richiesta al server di autorizzazione con nome utente nel campo username , password nel campo password e il server delle risorse a cui vuole accedere nel campo client_id .

  2. Il server di autorizzazione convalida il nome utente e la password e controlla se può generare una JWT per il server delle risorse richiesto.

  3. Restituisce un token se passano entrambi i controlli, il token contiene un attestato aud che corrisponde al client_id fornito nella richiesta.

posta Developer 05.12.2015 - 13:20
fonte

1 risposta

2

Everything that I have read explains that when requesting an access token from your authorization server you include the resource server URL as the client_id. This is then put in an aud claim within your JWT. Is this correct?

No, non lo è. Il 'client' è un'entità che perfeziona la richiesta e dovrebbe essere identificabile e verificata indipendentemente dal server di risorse (e possono esserci più client per la stessa risorsa) .
Specifica OAuth 2.0 fornisce la seguente definizione per client_id

a unique string representing the registration information provided by the client. The client identifier is unique to the authorization server.

Per il flusso del proprietario della risorsa le credenziali del client possono essere saltate solo se il client non è riservato ( link ), in altri casi sarebbe preferibile effettuare la pre-registrazione (client dovrebbe essere emesso univoco client_id e client_secret).

A proposito, secondo la specifica tu non hai bisogno qualsiasi credenziale del cliente per aggiornare il token di accesso . Gli unici parametri richiesti sono grant type (dovrebbe essere impostato su "refresh_token") e aggiornare il token stesso.

Riguardo al token JWT e alla rivendicazione "aud"

The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim.

In altre parole è un equivalente JWT per client_id. E le stesse regole di client_id sono applicabili. Ti consiglio di utilizzare la specifica OpenID Connect che è costruita su OAuth e ha un sacco di prescrizioni su come utilizzare i token JWT e il protocollo OAuth 2.0 nonché la spiegazione dettagliata dell'utilizzo delle attestazioni JWT.

Posso suggerire le seguenti opzioni al tuo problema

  1. Non utilizzare la rivendicazione "aud" nel flusso del proprietario della risorsa, poiché è facoltativa per OAuth (ma richiesta per OpenID Connect)
  2. Emetti un vero client_id e riempi "aud" di questo valore (in realtà dipende dal tipo di client - è confidenziale o meno)
risposta data 06.12.2015 - 21:54
fonte

Leggi altre domande sui tag