Stiamo pianificando di utilizzare JWT (token Web JSON) in un progetto di applicazione, ovvero un insieme di più servizi Web distribuiti che consentono l'autenticazione SSO (Single Sign-On). Quindi esiste un unico server di identità centrale che crea JWT. Ogni chiamata a uno dei servizi Web effettivi deve essere autenticata con una JWT precedentemente ottenuta dal client da quel server di identità.
La seguente idea è nata su come utilizzare coppie di chiavi RSA pubbliche / private per limitare i rischi per la sicurezza nella distribuzione delle chiavi.
Il server ha la sua coppia di chiavi RSA privata / pubblica. Quando crea un JWT, lo firma con la propria chiave PUBLIC. Il server di identità mantiene privata questa chiave "pubblica". Ma distribuisce la sua chiave "privata" a tutti i servizi. Quando un client utilizza tale JWT con uno dei servizi Web, il servizio utilizza la chiave RSA "privata" per decrittografare e verificare. I servizi non hanno bisogno di contattare il server di identità per la verifica, che è uno degli scopi dell'utilizzo di JWT in primo luogo.
In altre parole, i soliti ruoli dei tasti "privato" e "pubblico" sono invertiti. Ciò consentirebbe di generare una nuova coppia di chiavi RSA private / pubbliche relativamente frequentemente, come ogni giorno, per proteggere anche da violazioni temporanee della sicurezza sul server di identità / sequestro dell'hardware ecc. Chiunque in possesso della chiave "privata" non può generare JWT falso token per conto suo, perché non possiede la chiave del server "pubblico". Non importa nemmeno se qualcuno "ruba" quella chiave "privata" - possono solo verificare i token con essa.
Questo ha un vantaggio per gli scenari single-sign-on: il client deve ottenere una JWT solo una volta e può effettuare più chiamate a tutti i servizi che consentono tale token senza dover costantemente re-autenticarsi. Ovviamente il token avrebbe una vita breve come 1 ora. È utile quando sono necessari più servizi Web per ottenere un risultato di output finale singolo. (Non abbiamo lo scenario in cui sono coinvolte solo 2 parti in cui un server potrebbe utilizzare la chiave pubblica del destinatario per crittografare.)
A prima vista, questo appare come un ingegnoso metodo di sicurezza token JWT. Non sono riuscito a trovare alcun riferimento sul web fino a quando qualcuno lo ha implementato in questo modo. Ma sono sicuro che qualcun altro deve aver pensato a questo. Sembra sicuro, almeno a prima vista.
Esiste qualche esperienza o dati a cui non abbiamo pensato, che rende questo schema insicuro?