Devo archiviare i reclami dei miei utenti nel token JWT?

Sto usando i token JWT nelle intestazioni HTTP per autenticare le richieste a un server di risorse. Il server delle risorse e il server di autenticazione sono due ruoli di lavoro separati in Azure.

Non riesco a capire se devo archiviare le richieste nel token o allegarle alla richiesta / risposta in altro modo. L'elenco Reclami influisce sul rendering degli elementi dell'interfaccia utente sul lato client e sull'accesso ai dati sul server. Per questo motivo voglio assicurarmi che i reclami ricevuti dal server siano autentici e validati prima che la richiesta venga elaborata.

Esempi di rivendicazioni sono: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

I motivi per cui voglio usare il token JWT per loro sono:

Migliore protezione contro la modifica dei reclami lato client (ad es. Hacking dell'elenco dei sinistri).
Non è necessario cercare i reclami per ogni richiesta.

I motivi per cui non voglio usare il token JWT:

Il server di autenticazione deve quindi conoscere l'elenco dei reclami incentrato sull'app.
Il token diventa un unico punto di hack-entry.
Ho letto alcune cose dicendo che i token JWT non sono destinati ai dati a livello di app.

Mi sembra che entrambi abbiano degli svantaggi, ma mi sto inclinando verso l'inclusione di queste affermazioni nel token e voglio solo gestirlo da persone che hanno già affrontato questo problema.

NOTA: userò HTTPS per tutte le richieste API, quindi mi sembra che il token sarà sicuro 'abbastanza'. Sto usando AngularJS, C #, Web API 2 e MVC5.

— Astravagrant
fonte

leggendo questo ora .... e vorrei un aggiornamento se puoi. Sarei interessato a quello che hai fatto, visto che sto affrontando lo stesso .. pensando e mi manca il modo in cui alcune parti sono destinate a funzionare. l'utente riceve il token di autorizzazione, ma poi come devono essere portati i reclami ... potresti spiegarmi i tuoi risultati ... come probabilmente mi aiuterebbe.

— Seabizkit,

Risposte:

Nel mio jwt memorizzo solo le rivendicazioni identificative (userid, ecc.) (Crittografate).

Quindi, quando ottengo il token sul server (API), posso eseguire una ricerca lato server (db o API locale di rete) e recuperare tutte le associazioni nell'id utente (app, ruoli, ecc.)

Tuttavia, se vuoi aggiungere altro al jwt, fai attenzione alle dimensioni, poiché sarà probabilmente inviato su ogni richiesta, ma assicurati di crittografare i dati sensibili dei reclami.

— wchoward
fonte

Saluti, DL. Memorizzi nella cache i ruoli ecc. Sul server API o semplicemente colpisci il DB due volte ogni volta che ricevi una richiesta? (ovvero una volta per i ruoli e una volta per i dati effettivi richiesti). Se lo memorizzi nella cache, sarei interessato a sapere quale metodo usi. Inoltre, vuoi dire che hai ulteriormente codificato l'ID utente "all'interno" del token già crittografato? Grazie.

— Astravagrant,

Non sono ancora arrivato così lontano nella mia implementazione :), ma sì, stavo pensando di usare un server di cache in modo da non colpire il db così spesso e se un ruolo cambia la cache potrebbe essere rimossa per consentire il nuovo ruolo richiesto per il caricamento della cache salvata. Nel mio caso probabilmente userò Amazon AWS elsticache che si basa su memcached aperto ma più facile da configurare e utilizzare.

— wchoward,

Penso anche che sia una migliore idea ottenere tutte le informazioni necessarie sul server delle risorse e non memorizzarle in un token.

— Mateusz Migała,

quindi per ogni richiesta che ottieni i ruoli degli utenti ... reclami ..., potresti indicarmi un articolo o qualcosa che lo dimostra come fattibile. attualmente sto usando una sessione, ma sto cercando un modo migliore di fare le cose, ma la ricerca su ogni richiesta non ti sembra giusta?

— Seabizkit,

Sembra che l'autenticazione (chi è l'utente) e l'autorizzazione (cosa l'utente è autorizzato a fare) non sono così chiaramente divise come si vorrebbe.

Se non vuoi che il server di autenticazione sappia a cosa ha diritto l'utente, allora limita i reclami in quel JWT all'utente id proprio come suggerito da Wchoward. È possibile che un altro server noto come server di autorizzazione cerchi ciò a cui l'utente ha diritto.

Il passaggio di autorizzazione può essere eseguito dal server delle risorse quando viene presentato per la prima volta con un token di autenticazione dal client. Il server delle risorse invierebbe quindi un token al client contenente richieste di autorizzazione.

Nota: entrambi i JWT devono essere firmati con chiavi diverse.

Professionisti:

Autenticazione e autorizzazione sono gestite separatamente.
Il server di risorse non deve cercare l'autorizzazione per ogni richiesta.
L'interfaccia utente ha accesso per visualizzare l'autorizzazione ma non modificarla.

con:

Il client deve gestire due token anziché uno.
L'aggiunta di un server di autorizzazione aggiunge un'altra parte mobile da gestire.

— Chad Clark
fonte

Non dimenticare che anche quando controlli l'autorizzazione nell'interfaccia utente devi comunque controllare l'autorizzazione sul lato server quando arriva una richiesta.

— Chad Clark,