Estamos planeando utilizar JWT (tokens web JSON) en un proyecto de aplicación, que es un conjunto de múltiples servicios web distribuidos que permiten la autenticación SSO (inicio de sesión único). Así que hay un único servidor central de identidad que crea JWTs. Cada llamada a cualquiera de los servicios web reales debe ser autenticada con un JWT previamente obtenido por el cliente de ese servidor de identidad.
La siguiente idea surgió sobre cómo usar pares de claves RSA públicas / privadas para limitar los riesgos de seguridad en la distribución de claves.
El servidor tiene su propio par de claves RSA privadas / públicas. Al crear un JWT, lo firma con su propia clave PUBLIC. El servidor de identidad mantiene esta clave "pública" privada. Pero distribuye su clave "privada" a todos los servicios. Cuando un cliente usa un JWT con uno de los servicios web, el servicio usa la clave RSA "privada" para descifrar y verificar. Los servicios no necesitan ponerse en contacto con el servidor de identidad para la verificación, que es uno de los propósitos del uso de JWT en primer lugar.
En otras palabras, los roles habituales de las teclas "privada" y "pública" se invierten. Esto permitiría generar un nuevo par de claves RSA privadas / públicas con relativa frecuencia, como a diario, para proteger incluso contra violaciones de seguridad temporales en el servidor de identidad / incautación de hardware, etc. Cualquier persona que posea la clave "privada" no puede generar un JWT falso fichas por su cuenta, porque no posee la clave de servidor "pública". Ni siquiera importa si alguien "roba" esa clave "privada", solo pueden verificar tokens con ella.
Esto tiene una ventaja para los escenarios de inicio de sesión único: el cliente necesita obtener un JWT solo una vez y puede realizar múltiples llamadas a todos los servicios, lo que permite un token sin tener que volver a autenticarse constantemente. La ficha obviamente tendría un tiempo de vida corto como 1 hora. Ayuda cuando se requieren múltiples servicios web para obtener un resultado final único. (No tenemos el escenario donde solo 2 partes están involucradas donde un servidor podría usar la clave pública del destinatario para cifrar).
A primera vista, esto aparece como un ingenioso método de seguridad de tokens JWT. No pude encontrar ninguna referencia en la web hasta ahora para alguien implementándolo de esta manera. Pero estoy seguro de que alguien más debe haber pensado en esto. Parece seguro, al menos a primera vista.
¿Hay alguna experiencia o información que no hayamos pensado que haga que este esquema sea inseguro?