¿Debo almacenar mis reclamos de usuario en el token JWT?

Estoy usando tokens JWT en encabezados HTTP para autenticar solicitudes a un servidor de recursos. El servidor de recursos y el servidor de autenticación son dos roles de trabajo separados en Azure.

No puedo decidir si debo almacenar los reclamos en el token o adjuntarlos a la solicitud / respuesta de alguna otra manera. La lista de Reclamaciones afecta la representación de elementos de la IU del lado del cliente, así como el acceso a los datos en el servidor. Por este motivo, quiero asegurarme de que los reclamos recibidos por el servidor sean auténticos y validados antes de que se procese la solicitud.

Ejemplos de reclamos son: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Las razones por las que quiero usar el token JWT para ellos son:

Mejor protección contra la edición de reclamos del lado del cliente (es decir, piratear la lista de reclamos).
No es necesario buscar los reclamos en cada solicitud.

Las razones por las que no quiero usar el token JWT:

El servidor de autenticación debe conocer la lista de notificaciones centrada en la aplicación.
El token se convierte en un único punto de entrada de hack.
He leído algunas cosas que dicen que los tokens JWT no están destinados a datos de nivel de aplicación.

Me parece que ambos tienen inconvenientes, pero me estoy inclinando hacia la inclusión de estas afirmaciones en el token y solo quiero ejecutar esto por personas que han tratado con esto antes.

NOTA: Usaré HTTPS para todas las solicitudes de API, por lo que me parece que el token será seguro 'suficiente'. Estoy usando AngularJS, C #, Web API 2 y MVC5.

— Astravagante
fuente

leyendo esto ahora ... y me gustaría una actualización si puedes. Me interesaría lo que hiciste, ya que estoy enfrentando lo mismo ... pensando y me falta cómo algunas de las partes están destinadas a funcionar. el usuario obtiene un token de autorización, pero entonces, ¿cómo deben llevarse las reclamaciones ... podría explicar sus hallazgos ... ya que probablemente me ayudaría.

— Seabizkit

Respuestas:

Solo almaceno los reclamos de identificador (ID de usuario, etc.) (encriptados) en mi jwt.

Luego, cuando obtengo el token en el servidor (API), puedo hacer una búsqueda en el lado del servidor (db o llamada a la API de la red local) y recuperar todas las asociaciones al ID de usuario (aplicaciones, roles, etc.)

Sin embargo, si desea agregar más información al jwt, solo tenga cuidado con el tamaño, ya que es probable que se envíe en cada solicitud, pero asegúrese de cifrar los datos confidenciales de las reclamaciones.

— wchoward
fuente

Saludos, DL. ¿Guarda en caché los roles, etc. en el servidor API, o simplemente presiona el DB dos veces cada vez que recibe una solicitud? (es decir, una vez para los roles y otra para los datos reales que se solicitan). Si lo almacena en caché, me interesaría saber qué método utiliza. Además, ¿quiere decir que aún encripta el ID de usuario 'dentro' del token ya encriptado? Gracias.

— Astravagrant

Todavía no he llegado tan lejos en mi implementación :), pero sí, estaba pensando en usar un servidor de almacenamiento en caché para que de esa manera no golpeara el db con tanta frecuencia y si un rol cambia, el caché podría eliminarse para permitir el nuevo rol consultado para ser cargado caché guardado. En mi caso, probablemente usaría Amazon AWS elsticache, que se basa en la memoria caché abierta pero es más fácil de configurar y usar.

— wchoward

También creo que es una mejor idea obtener toda la información necesaria en el servidor de recursos y no almacenarlos en un token.

— Mateusz Migała

así que por cada solicitud que obtenga los roles de los usuarios ... reclamos ..., ¿podría indicarme un artículo o algo que muestre que esto es factible? Actualmente estoy usando sesión, pero estoy buscando una mejor manera de hacer las cosas, pero ¿no parece correcto buscar en cada solicitud?

— Seabizkit

Parece que la autenticación (quién es el usuario) y la autorización (lo que el usuario puede hacer) no están tan claramente divididas como usted quisiera.

Si no desea que el servidor de autenticación sepa a qué tiene derecho el usuario, limite las reclamaciones en ese JWT al ID de usuario tal como lo sugirió wchoward. Podría hacer que otro servidor conocido como el servidor de autorización busque lo que tiene derecho el usuario.

El servidor de recursos puede realizar el paso de autorización cuando el cliente le presenta por primera vez un token de autenticación. El servidor de recursos luego enviaría un token al cliente que contiene notificaciones de autorización.

Nota: Ambos JWT deben estar firmados por diferentes claves.

Pros:

La autenticación y la autorización se gestionan por separado.
El servidor de recursos no tiene que buscar autorización en cada solicitud.
La interfaz de usuario tiene acceso para ver la autorización pero no para editarla.

Estafa:

El cliente necesita manejar dos tokens en lugar de uno.
Agregar un servidor de autorización agrega otra parte móvil para administrar.

— Chad Clark
fuente

No olvide que incluso cuando verifica la autorización en la interfaz de usuario, aún debe verificar la autorización en el lado del servidor cuando llega una solicitud.

— Chad Clark