Segreto condiviso quando si utilizza JWT con un HMAC per l'autenticazione

7

Attualmente sto implementando l'autenticazione utente su un'API REST-like utilizzata da un client Android. Dopo alcune ricerche, penso che JWT (Token Web JSON) sia un buon modo per farlo.

La procedura di base che ho pianificato è: l'utente accede usando nome utente / password (su HTTPS). Il server convalida la password e quindi genera un JWT che include un qualche tipo di ID utente, che lo firma con RS256 (asimmetrico usando RSA, quindi il client ha solo la chiave pubblica corrispondente) e lo invia al client. Per effettuare una chiamata API, il client invierà il JWT al server. Tutto il server quindi convalida il JWT usando la sua chiave privata, e controlla anche che l'algoritmo della firma sia quello atteso dal server. Se la convalida ha esito positivo, il server può fidarsi dell'ID utente nel token. Un client non può fingere di essere un utente diverso, perché avrebbe bisogno della chiave privata del server per generare una firma corretta se il carico utile del JWT è stato modificato.

Supponiamo ora di voler usare HS256 (simmetrico usando un HMAC), forse perché la firma risultante è più corta. Per quanto riguarda il mio buon senso, in questo caso, solo il server può conoscere la chiave (singola).

Ma qui arriva la confusione: leggendo su utilizzando HS256 con JWT, alcuni siti che ho visto sembrano suggerire che la chiave è un "segreto condiviso", il che significa che sia il server che il client lo sanno. Ma se questo è il caso, il client potrebbe semplicemente modificare il carico utile del JWT e creare una firma valida usando la chiave condivisa. Qualsiasi utente loggato potrebbe quindi fingere di essere qualsiasi altro utente semplicemente modificando l'ID utente nel JWT, quindi non è meglio che non convalidare una firma. C'è qualcosa che mi manca o semplicemente non ha senso consentire al client l'accesso alla chiave quando si usa HS256? Ho erroneamente letto i siti suggerendo che la chiave HS256 è condivisa?

L'unico modo in cui potevo pensarlo avrebbe permesso a entrambe le parti di sapere che la chiave utilizza una chiave separata per ciascun utente. Ma anche in questo caso, qualsiasi dato di payload JWT tranne l'ID utente (ad esempio un flag "isAdmin") potrebbe ancora essere modificato a piacimento.

    
posta Alemarius Nexus 25.01.2017 - 22:00
fonte

1 risposta

4

"Segreto condiviso" in questo caso significa in genere tra più server, non tra il client e il server. In genere, le JWT possono essere eseguite utilizzando la crittografia simmetrica - nel qual caso tutti i server che devono verificare il token devono avere il segreto condiviso - o la crittografia asimmetrica, nel qual caso solo il server che esegue effettivamente l'autenticazione deve avere la chiave privata, altri server possono semplicemente utilizzare la chiave pubblica per verificare che il token sia firmato in modo appropriato.

In nessun caso un cliente deve avere la possibilità di modificare il suo token - riceve il token al momento della presentazione delle credenziali, quindi usa il token per ottenere servizi, dallo stesso server o da altri server che condividono una relazione di fiducia con il autorizzazione del server (tramite la conoscenza della chiave pubblica / privata o tramite una chiave condivisa)

    
risposta data 25.01.2017 - 22:09
fonte

Leggi altre domande sui tag