Asegurar que el Cliente está autorizado para usar el token web JSON

3
Los

JSON Web Tokens (JWT) son objetos firmados por el servidor que el servidor emisor utiliza para identificar a un usuario, rastrear datos de sesión y autorizar solicitudes.

El hecho de que JWT esté firmado por el servidor garantiza que el token fue producido por alguien con acceso a la clave simétrica compartida o privada del servidor, pero - qué mecanismo existe para garantizar que el token se envía a la servidor por un usuario autorizado?

Por ejemplo, digamos que tengo un servidor que emite un JWT al mundo. Independientemente de si transmito o no ese token a través de una conexión segura, ya que el cliente puede guardar, descifrar y retransmitir los datos, parece seguro asumir que una vez que un cliente tiene un token web, todos tienen ese token web.

Entonces, ¿cómo debo asegurarme en mi servidor de que los tokens que llegan a través del cable realmente provienen de partes autorizadas?

    
pregunta StudentsTea 01.09.2015 - 23:13
fuente

2 respuestas

4

En una oración: tienes que confiar en el cliente para que use TLS y generalmente proteger el token.

Como muchos sistemas de token, JWT confía en el cliente para asegurar su token. Los clientes ya deben mantener las credenciales necesarias para la autenticación (por ejemplo, contraseñas), por lo que este no es un concepto radicalmente diferente. Además, los JWT suelen tener un tiempo de caducidad mucho más corto que las credenciales, por lo que protegerlos suele ser más fácil.

A continuación hay algunos fragmentos de las especificaciones relevantes.

El JWT RFC , que utiliza el JSON Web Signature RFC , requiere el uso de TLS:

  

Para protegerse contra la divulgación de información y la manipulación, la protección de confidencialidad DEBE aplicarse mediante TLS con un conjunto de cifrado que brinda confidencialidad e integridad.

Los JWT son similares al concepto OAuth 2.0 de tokens de portador . El token RFC del portador indica:

  

Cualquier parte que posea un token de portador (un "portador") puede usarlo para obtener acceso a los recursos asociados (sin demostrar la posesión de una clave criptográfica). Para evitar el uso indebido, los tokens del portador deben estar protegidos contra divulgación en el almacenamiento y en el transporte.

En la sección 5.2 continúa diciendo que TLS debe usarse para garantizar la seguridad del token en tránsito, tanto al obtener el token como al usarlo:

  

Esto requiere que la interacción de comunicación entre el cliente y el servidor de autorización, así como la interacción entre el cliente y el servidor de recursos, utilicen la confidencialidad y la protección de integridad.

    
respondido por el Neil Smithline 01.09.2015 - 23:36
fuente
1

Pregunte al propietario de la información si autoriza la solicitud.

Como señala Neil Smithline en su excelente respuesta a esta pregunta , los RFC en JWT, OAuth y muchos otros sistemas de autenticación basados en token se basan en que el usuario final mantiene el secreto de su token.

Para mí, personalmente, es una píldora difícil de tragar: muchos usuarios finales no entienden qué es un token o incluso dónde está, y mucho menos por qué o cómo deberían asegurarlo.

Si bien esto puede sonar tan fundamental, es delicado señalar: si un usuario final tiene consciente de que alguien está intentando acceder a su información privada, o si un usuario final es consciente de que la privacidad de su clave ha sido comprometido, se podría argumentar que es mucho más probable que alerten a las partes interesadas de que algo salió mal.

Por lo tanto, uno podría concluir que la tarea en cuestión es diseñar un sistema por el cual sea fácil para los usuarios finales saber cuándo se está accediendo a su información privada, cuando se está utilizando su token. Si bien no podemos diseñar un sistema que no confíe en la confianza, podemos diseñar un sistema que vincule la protección de la clave con los intereses que el usuario ya tiene y sabe cómo administrar.

En una implementación hipotética de un sistema que usa tokens web, uno podría experimentar con lo siguiente:

  1. Realice pruebas en la infraestructura de la aplicación para asegurarse de que está utilizando Perfect Forward Security.
  2. Pregunte a los clientes que acceden a la infraestructura de la aplicación quiénes son.
  3. Busque la identificación proporcionada por el cliente en un sistema interno que asigna la identificación a un teléfono celular, y comuníquese con ese teléfono celular.
  4. El mensaje enviado al teléfono proporcionará la mayor cantidad de información posible sobre el cliente, y le preguntará a la persona que tiene el control del teléfono si el cliente debe tener autorización para usar la infraestructura de la aplicación.
  5. Si el cliente está autorizado por la persona que controla el teléfono, emita un token para el cliente y mantenga un registro de cómo se usa el token. Además, comparta las partes pertinentes de ese registro con el teléfono registrado.
  6. Caduca el token después de un corto período de tiempo; rechazar cualquier otra solicitud utilizando ese token.

Si bien los pasos anteriores no forman parte de los RFC en los tokens web de JSON, OAuth o muchos otros sistemas de autenticación basados en token, parcialmente desplaza el problema de la confianza de un usuario que no sabe cómo mantener un token seguro a un grupo de ingenieros que, idealmente, saben cómo implementar bien la autenticación de dos factores.

    
respondido por el StudentsTea 02.09.2015 - 02:06
fuente

Lea otras preguntas en las etiquetas