Autorizzazioni e ruoli di accesso devono essere inclusi nel payload di JWT?

Le informazioni su autorizzazioni e ruoli del client devono essere incluse in JWT?

Avere tali informazioni nel token JWT sarà molto utile poiché ogni volta che arriva un token valido, sarebbe più semplice estrarre le informazioni sull'autorizzazione dell'utente e non sarà necessario chiamare il database per lo stesso. Ma includere tali informazioni e non ricontrollare le stesse nel database sarà un problema di sicurezza?

Informazioni come quella sopra menzionata non dovrebbero mai far parte di JWT e solo il database dovrebbe essere utilizzato per controllare i ruoli di accesso e le autorizzazioni di un utente?

security authentication jwt

— Anshul Sahni
fonte

Risposte:

Lo scopo di includere le attestazioni nel token è quindi non è necessario disporre di tale comunicazione tra la risorsa e il provider di autenticazione.

La risorsa può semplicemente verificare che il token abbia una firma valida e fidarsi del contenuto.

Supponendo che la chiave privata sia privata per il server di autenticazione, si è bravi. Alcuni provider cambiano le loro chiavi per mitigare il rischio.

Se ci pensate, se la risorsa ha richiamato il server di autenticazione per ottenere i reclami. Quindi sta essenzialmente assicurando che stia parlando con il server giusto con metodi di fiducia simili.

— Ewan
fonte

Bene, grazie per una bella risposta, posso sapere di più su cosa intendevi dalla tua dichiarazione "Alcuni provider cambiano le loro chiavi per mitigare il rischio". ?

— Anshul Sahni,

Pertanto, anziché disporre di una chiave di firma fissa, il provider di autorizzazione la cambierà ogni tanto e fornirà un endpoint ai server di risorse per scaricare la metà pubblica di essa. Le risorse devono effettuare chiamate al server di autorizzazione ogni tanto, ma non una volta per richiesta

— Ewan

Quindi tutti i token non sono validi ogni volta che la firma della chiave viene cambiata dal servizio

— Anshul Sahni,

di solito avranno più di una chiave possibile, in modo che i token in volo non vengano invalidati. il token conterrà un "ID chiave" per indicare alla risorsa quale utilizzare

— Ewan,

L'unica cosa che mi manca qui è come procedere quando i dati nel JWT sono invalidati. Supponiamo che i ruoli siano cambiati sul lato server ma il client detenga ancora il token con tutti i set di ruoli. Devi essere in grado di revocare i token sul lato server in modo che quei token che contengono informazioni obsolete non siano più validi e utilizzabili per ulteriori richieste. Ciò è in linea con ciò che Ewans suggerisce in qualche modo (consentendo al server di revocare il token) per l'una o l'altra ragione.

— Laiv

Dalla mia esperienza, se tutti i tuoi sistemi utilizzano un ruolo centrale e un database di autorizzazioni, puoi aggiungere tutto ciò in JWT.

Tuttavia, questo approccio potrebbe non funzionare bene negli scenari SSO quando il server auth stesso non ha alcuna idea del sistema di destinazione che riceverà e si fiderà del token.

I ruoli e le autorizzazioni dell'utente sono interamente sul destinatario del token JWT. È particolarmente vero quando si integra l'autenticazione SSO con JWT in alcuni sistemi legacy che hanno già il loro sottosistema di autorizzazioni in atto e quindi hanno bisogno di un solo reclamo per essere presenti in JWT: il reclamo dell'identità dell'utente.

— JustAMartin
fonte

Sono d'accordo su questo Le autorizzazioni utente non dovrebbero far parte di jwt specialmente in SSO poiché l'idp non è a conoscenza di quali altri servizi questo utente jwt sta per parlare .. invece la risorsa dovrebbe implementare la parte di autorizzazione una volta che l'identità è stata confermata per l'utente

— Manish Rawat,

Concordo anche sul fatto che le richieste di autorizzazione nei JWT non siano una buona idea al di là di una semplice API monolitica. Ho scritto un post sul blog a riguardo: sdoxsee.github.io/blog/2020/01/06/…

— sdoxsee