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

14

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

No puedo dejar de pensar si debo almacenar las reclamaciones en el token o adjuntarlas a la solicitud / respuesta de alguna otra manera. La lista de Reclamaciones afecta la representación de los 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 las reclamaciones recibidas por el servidor sean auténticas y estén validadas antes de que se procese la solicitud.

Algunos ejemplos de reclamaciones son: CanEditProductList, CanEditShopDescription, CanReadUserDetails.

Los motivos por los que quiero usar el token JWT para ellos son:

  • Mejor protección contra la edición del lado del cliente de las reclamaciones (es decir, pirateando la lista de reclamaciones).
  • No es necesario buscar las reclamaciones en cada solicitud.

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

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

Me parece que ambos tienen inconvenientes, pero me estoy inclinando hacia la inclusión de estas reclamaciones en el token y solo quiero que lo hagan las personas que han tratado esto antes.

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

    
pregunta Astravagrant 18.02.2015 - 18:38

2 respuestas

6

Almaceno solo las reclamaciones de identificadores (ID de usuario, etc.) (encriptadas) en mi jwt.

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

Sin embargo, si desea introducir más en el jwt, 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.

    
respondido por el wchoward 18.02.2015 - 23:57
2

Parece que la autenticación (quién es el usuario) y la autorización (qué se le permite al usuario) no están tan claramente divididas como 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 compruebe a qué tiene derecho el usuario.

El servidor de recursos puede realizar el paso de autorización cuando se presenta por primera vez con un token de autenticación por parte del cliente. El servidor de recursos enviaría un token al cliente que contiene las reclamaciones de autorización.

Nota: ambos JWT deben estar firmados por claves diferentes.

Pros:

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

Con:

  • El cliente debe manejar dos tokens en lugar de uno.
  • Agregar un servidor de autorización agrega otra parte móvil para administrar.
respondido por el Chad Clark 05.02.2016 - 22:24

Lea otras preguntas en las etiquetas