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.