¿Deberían incluirse los permisos y roles de acceso en la carga útil de JWT?

¿Debería incluirse información sobre los permisos y roles del cliente en JWT?

Tener dicha información en el token JWT será muy útil ya que cada vez que llega un token válido, sería más fácil extraer la información sobre el permiso sobre el usuario y no será necesario llamar a la base de datos para obtener el mismo. Pero, ¿incluir esa información y no volver a verificar la misma en la base de datos será un problema de seguridad?

¿Información como la mencionada anteriormente no debería ser parte de JWT nunca, y solo la base de datos debería usarse para verificar los roles de acceso y los permisos de un usuario?

security authentication jwt

— Anshul Sahni
fuente

Respuestas:

El propósito de incluir reclamos en el token es para que no tenga que tener esa comunicación entre el recurso y el proveedor de autenticación.

El recurso solo puede verificar que el token tenga una firma válida y confiar en el contenido.

Suponiendo que la clave privada es privada para el servidor de autenticación, es bueno. Algunos proveedores cambian su clave para mitigar el riesgo.

Si lo piensa, si el recurso realizó una llamada al servidor de autenticación para obtener los reclamos. Entonces, esencialmente se está asegurando de que está hablando con el servidor correcto mediante métodos de confianza similares.

— Ewan
fuente

Bueno, gracias por una hermosa respuesta, ¿puedo saber más sobre lo que quisiste decir de tu declaración? "Algunos proveedores cambian su clave para mitigar el riesgo". ?

— Anshul Sahni

Entonces, en lugar de tener una clave de firma fija, el proveedor de autenticación la cambiará de vez en cuando y proporcionará un punto final para que los servidores de recursos descarguen la mitad pública. Los recursos tienen que hacer llamadas al servidor de autenticación de vez en cuando, pero no una vez por solicitud

— Ewan

Por lo tanto, todos los tokens no son válidos cada vez que el servicio cambia la firma de la clave

— Anshul Sahni

Por lo general, tendrán más de una clave posible, de modo que las fichas en vuelo no se invaliden. el token contendrá un 'ID de clave' para indicarle al recurso cuál usar

— Ewan

Lo único que extraño aquí es cómo proceder cuando se invalidan los datos en el JWT. Digamos que los roles cambiaron en el lado del servidor, pero el cliente aún tiene el token con todo el conjunto de roles. Debe poder revocar los tokens en el lado del servidor para que los tokens que contienen información desactualizada ya no sean válidos y puedan utilizarse para otras solicitudes. Esto está en línea con lo que Ewans sugiere de alguna manera (permitiendo que el servidor revoque el token) por una u otra razón.

— Laiv

Desde mi experiencia, si todos sus sistemas están utilizando alguna función central y base de datos de permisos, puede agregar todo eso a JWT.

Sin embargo, este enfoque podría no funcionar bien en escenarios de SSO cuando el servidor de autenticación en sí no tiene idea alguna sobre el sistema de destino que recibirá y confiará en el token.

Los roles y permisos del usuario están enteramente sobre el receptor del token JWT. Es especialmente cierto cuando integra la autenticación SSO con JWT en algunos sistemas heredados que ya tienen su subsistema de permisos y, por lo tanto, solo necesitan un reclamo para estar presente en JWT: el reclamo de identidad del usuario.

— JustAMartin
fuente

Estoy de acuerdo en esto Los permisos de usuario no deberían ser parte de jwt, especialmente en SSO, ya que el idp no sabe con qué otros servicios va a hablar este usuario jwt ... en cambio, el recurso debe implementar la parte de autorización una vez que la identidad ha sido confirmada para el usuario

— Manish Rawat

También estoy de acuerdo en que las solicitudes de permisos en JWT no son una buena idea más allá de una simple API monolítica. Escribí una publicación de blog al respecto: sdoxsee.github.io/blog/2020/01/06/…

— sdoxsee