asp.net + token de portador: ¿Es posible la manipulación de reclamaciones?

1

Estoy experimentando con una autenticación OAuth2 en un servicio web de asp.net.

Al generar accidentalmente una gran cantidad de reclamaciones, he descubierto que el token del portador aumenta drásticamente en tamaño. Eso me lleva a suponer que las reclamaciones y otras posibles informaciones relacionadas con la autorización se almacenarán en el token del portador.

(Anteriormente tenía la impresión de que el token de portador es simplemente otro tipo de ID de sesión y las reclamaciones / roles donde se almacenaba en el lado del servidor)

Mis suposiciones:

  • Las reclamaciones de identidad se almacenan en el token del portador y, por lo tanto, el cliente puede acceder a ellas.
  • Me siento alentado por las pautas del desarrollador (MSDN, StackOverFlow) para almacenar información relacionada con la identidad en las reclamaciones (por ejemplo, "ClientID" = xxxx, "CanViewSensitiveData" = true, etc.). Lo consideré "estado del arte".

La combinación de los dos puntos parece ser incorrecta. Para enviar / recibir datos confidenciales de autenticación / autorización a / desde el cliente se ofrecería la posibilidad de que un cliente no autorizado manipule el token del portador y cambie los reclamos / roles contenidos. Anteriormente, con el uso del sessionId, se mitigó con una generación aleatoria del sessionID y la gran entropía.

Estoy seguro de que los inventores de esta tecnología / protocolo ya impidieron la manipulación de los datos contenidos, pero no estoy seguro de cómo. ¿Alguien podría arrojar algo de luz sobre este asunto? ¿Mis suposiciones están equivocadas o hay algún tipo de firma de token involucrada?

    
pregunta Dr. Grauert 20.02.2017 - 21:14
fuente

1 respuesta

2

A menos que use una configuración insegura de homebrew de OAuth2, o deshabilite explícitamente las validaciones de token; sus tokens están firmados criptográficamente por el emisor. Tal como está escrito en el RFC :

  

El JWT DEBE estar firmado digitalmente o tener un Código de autenticación de mensaje (MAC) aplicado por el emisor. El servidor de autorización DEBE rechazar los JWT con una firma o MAC no válidos.

La desventaja de poner muchas reclamaciones en su token JWT es que podría ser "cortado" si supera la longitud máxima de un encabezado HTTP. Apache es 8kB, IIS es 16kB.

Por lo general, se adhiere al uso de (nuevas) bibliotecas probadas y no deshabilite las llamadas de validación de token y no debería tener mucho de qué preocuparse. Si un adversario puede "hacerse pasar" por un emisor de fichas, entonces esa es una historia diferente.

    
respondido por el ndrix 20.02.2017 - 22:37
fuente

Lea otras preguntas en las etiquetas