Header Ads Widget

Ticker

6/recent/ticker-posts

¿Por qué no puedo enviar JWT sin OAuth?


 Un JSON Web Token o JWT es un estándar extremadamente poderoso. Es un objeto JSON firmado; un formato de token compacto que a menudo se intercambia en encabezados HTTP para cifrar las comunicaciones web.

Debido a su poder, los JWT se pueden encontrar impulsando algunas de las implementaciones de API modernas más grandes. Para muchos, el JWT representa una gran solución que equilibra el peso con la eficiencia y, como tal, suele ser un estándar muy atractivo de adoptar para la seguridad de API .

Sin embargo, un JWT no debe verse como una solución completa . Desafortunadamente, parece que hay algunos malentendidos importantes sobre qué es un JWT y cómo funciona exactamente. En muchas situaciones, depender únicamente de los JWT puede ser extremadamente peligroso.

Una de las preguntas más comunes sobre el uso de JWT es: ¿Por qué no puedo enviar JWT sin OAuth? Hoy vamos a responder esa misma pregunta. Definiremos qué es realmente un JWT, cómo funciona y por qué es peligroso adoptarlo de forma aislada.

¿Qué es un JWT?

Que es un JWT

Antes de abordar por qué el uso de JWT solo es inseguro, debemos definir qué es realmente un JWT . Esto se debe a que los JWT a menudo se combinan con los protocolos y sistemas adicionales que los rodean, lo que significa que el concepto de diseño de JWT se ha reforzado más allá de la definición real del objeto en sí.

JWT es un estándar abierto definido por RFC 7519 . Los autores consideran que el JWT es una "forma compacta y autónoma de transmitir información de forma segura entre las partes como un objeto JSON ". El propio JWT se compone de un encabezado , una carga útil y una firma que prueba la integridad del mensaje al servidor receptor.

El contenido codificado dentro de un JWT está firmado digitalmente , ya sea utilizando un secreto utilizando el algoritmo HMAC o aprovechando el modelo de Infraestructura de clave pública ( PKI ) con una configuración RSA privada / pública. Si bien esto brinda una cierta cantidad de protección de integridad, no garantiza específicamente la seguridad ; discutiremos esto con mayor detalle en solo un momento, pero debe entenderse que un JWT es un formato de codificación, y solo un formato de codificación .

Los JWT son amados porque son pequeños y se prestan a un transporte eficiente como parte de una URL, como parte del parámetro POST o incluso dentro del encabezado HTTP. Existen opciones de transporte más ligeras y existen más extensiones del concepto; CWT es un gran ejemplo, utilizando CBOR , o Representación Concisa de Objetos Binarios, para reducir aún más el tamaño del paquete y mejorar la eficiencia.

El principal beneficio (y quizás el principal inconveniente desde el punto de vista de la seguridad) del estándar JWT es que el paquete codificado es autónomo. El paquete JWT contiene todo lo que el sistema necesitaría saber sobre el usuario y, como tal, puede entregarse como un objeto singular.

Lea también: El uso de estándares abiertos es fundamental para la longevidad de la API

Los peligros de una solución solitaria

Los JWT son poderosos, simplemente no se puede negar eso. Desafortunadamente, muchos desarrolladores parecen pensar que JWT es más que una metodología de codificación, sino una implementación completa y segura. A menudo, esto se debe a que los JWT generalmente se combinan con un protocolo y un estándar de cifrado adecuados en la naturaleza, pero esta es una elección consciente, no el resultado de una seguridad automática debido a la estructura del JWT en sí.

Un JWT solo es seguro cuando se usa junto con metodologías de cifrado y seguridad de transporte . JWT es una gran metodología de codificación, pero no es una medida de seguridad holística. Sin protocolos adicionales que lo respalden, un JWT no es más que una clave API ciertamente liviana y un poco más segura .

Para ver un ejemplo de esta inseguridad, veamos un caso de uso común. Una API web sirve como backend para una aplicación web, y cuando el usuario genera un JWT, se almacena como un elemento de almacenamiento de datos HTML5. Esto se hace para ayudar en la utilización de la API en múltiples puertas de enlace y funciones.

En esta situación común, el problema es que el JWT está esencialmente expuesto para uso común. El JWT está firmado digitalmente, lo que asegura una cierta cantidad de integridad garantizada. El servidor en sí también está configurado para rechazar cualquier JWT con un componente de Encabezado, Carga útil o Firma manipulado y, como tal, puede rechazar un token JWT modificado. Dicho esto, no es necesario modificar el token para violar la seguridad. En teoría, un atacante podría tomar ese token y usarlo en una especie de ataque de repetición, obteniendo recursos para los que no está autorizado.

Si bien este tipo de ataque se puede mitigar un poco mediante el uso de fechas de vencimiento, esto no hace nada para los ataques man-in-the-middle . En el esquema de ataque MITM, el vencimiento no importa, ya que el ataque se inicia en vivo como intermediario.

Todos estos problemas surgen del simple hecho de que los JWT son un mecanismo para transferir datos, no para protegerlos.

Lea nuestra inmersión profunda en OAuth y OpenID Connect

Asegurar los JWT

Los JWT son soluciones autónomas que contienen todo lo que el servidor necesita saber sobre quién es el usuario, qué necesita y qué está autorizado a hacer. En consecuencia, son excelentes para la autenticación sin estado y funcionan bien con estos métodos orientados a entornos sin estado .

Si bien hay una serie de soluciones e implementaciones de terceros de autenticación sin estado, el hecho es que lo que esencialmente estaría creando es un token de portador o, alternativamente, un token de acceso .

Está bien, y de hecho, lo que queremos hacer, pero esto plantea una pregunta simple: si de hecho estamos creando un token de portador de este tipo, ¿por qué no utilizar la funcionalidad incorporada del esquema OAuth diseñado específicamente para trabajar con JWT? Ya hay una gran cantidad de funciones de seguridad incorporadas en la especificación OAuth que están diseñadas específicamente para admitir JWT, por lo que el uso de soluciones externas , a menudo la segunda pregunta después de por qué no puedo enviar JWT sin OAuth , no tiene sentido.

Si utilizamos el estándar de uso de token de portador OAuth 2.0 según RFC 6750 , que incorpora encabezados de autorización, básicamente podemos crear JWT que serían reconocidos y tratados especialmente por una amplia variedad de dispositivos, desde proxies HTTP hasta servidores. De ese modo, reduciríamos la fuga de datos, el almacenamiento no intencionado de solicitudes (como se muestra arriba) y permitiríamos el transporte a través de algo tan simple como HTTPS.

Aprenda también: Cómo manejar el procesamiento por lotes con OAuth 2.0

Utilización adecuada de JWT

Si bien es importante proteger sus JWT, también es importante indicar cómo se vería la utilización adecuada de un JWT dentro del esquema OAuth. Si bien un JWT puede cumplir muchas funciones, echemos un vistazo a un caso de uso común en forma de token de acceso . Tanto OAuth 2.0 como OpenID Connect son vagos en cuanto al tipo de access_token, lo que permite una amplia gama de funciones y formatos. Dicho esto, la utilización de un JWT como ese token es bastante ubicua, por los beneficios en eficiencia y tamaño ya mencionados.

Un token de acceso es, en términos simples, un token que utiliza la API para realizar solicitudes en nombre del usuario que solicitó el token. Es parte del mecanismo de autorización fundamental dentro de OAuth y, como tal, la confidencialidad y la integridad son extremadamente importantes. Para generar un token de acceso, se requiere un código de autorización . Todos los elementos de este código también son extremadamente importantes para mantener la confidencialidad y la seguridad.

En consecuencia, un JWT encaja en este papel casi a la perfección. Debido a los estándares mencionados anteriormente que permiten la transmisión a través de HTTPS, el JWT puede contener toda la información necesaria para generar el token de acceso. Una vez que se genera el token, también se puede mantener en forma JWT como lo que se llama un token de acceso autocodificado .

El beneficio clave de manejar la codificación del token de acceso de esta manera en el esquema de OAuth 2.0 es que las aplicaciones no tienen que entender su esquema de token de acceso; toda la información está codificada dentro del token en sí, lo que significa que el esquema puede cambiar fundamentalmente sin requerir que los clientes sean conscientes, o incluso afectados, por tales cambios.

Además, el JWT es ideal para esta aplicación debido a la amplia gama de bibliotecas que ofrecen funciones como la caducidad. Un buen ejemplo de esto sería la biblioteca Firebase PHP-JWT , que ofrece dicha funcionalidad de caducidad.

El siguiente código se toma de la documentación oficial de OAuth y demuestra cómo se vería dicha implementación durante la codificación:

 $user_id,
 
  # Issuer (the token endpoint)
  'iss' => 'https://' . $_SERVER['PHP_SELF'],
 
  # Audience (intended for use by the client that generated the token)
  'aud' => $client_id,
 
  # Issued At
  'iat' => time(),
 
  # Expires At
  'exp' => time()+7200, // Valid for 2 hours
 
  # The list of OAuth scopes this token includes
  'scope' => $scope
);
$token_string = JWT::encode($token_data, $jwt_key);

Tal mecanismo daría como resultado una cadena codificada que se ve así:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOjEwMDAsImlzcyI6Imh0dHBzOi8 vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuY29tIiw iYXVkIjoiaHR0cHM6Ly9leGFtcGxlLWFwcC5 jb20iLCJpYXQiOjE0NzAwMDI3MDMsImV4cCI 6MTQ3MDAwOTkwMywic2NvcGUiOiJyZWFkIHd yaXRlIn0.zhVmPMfS3_Ty4qUl5ZMh4TipXsU CSH0mHzb4P_Ijhxs

Advertencias

Por supuesto, al igual que con cualquier implementación de seguridad, hay que tener en cuenta algunas advertencias. En el caso de JWT como una solución de autorización autocodificada, se deben considerar los ataques de reproducción. Si bien la adopción de metodologías de cifrado adecuadas debería negar muchos de esos problemas, el hecho es que el problema sigue siendo fundamental para el concepto en su conjunto, y probablemente debería abordarse como una posibilidad en lugar de una amenaza imposible.

En consecuencia, almacenar en caché el código de autorización durante la vida útil del código es la solución sugerida por OAuth. Al hacer esto, el código se puede verificar con el código almacenado en caché conocido para verificar su validez e integridad, y una vez que se alcanza la fecha de vencimiento, se rechaza automáticamente por razones de fecha.

También debe tenerse en cuenta que, debido a la naturaleza del JWT, una vez que se emite un código de autorización, el JWT es autónomo; como tal, técnicamente no se puede invalidar, al menos en su configuración más básica. El JWT está diseñado para no llegar a la base de datos en cada verificación, y cuando se usa un secreto global, el JWT es válido hasta el vencimiento.

Hay algunas formas de evitar esto, como agregar un contador en el JWT que se incrementa en ciertos eventos (como cambio de rol, cambio de datos de usuario, etc.). Por supuesto, esto da como resultado un sondeo de la base de datos para cada solicitud, pero la cantidad de datos que se verifican es lo suficientemente minúscula como para que cualquier aumento de procesamiento sea algo insignificante.

Además, al menos en teoría, podría utilizar secciones para funciones, dominios y ámbitos específicos, y cambiar ese secreto cuando se descubra una infracción. Si bien esto afectaría a más usuarios de los que les gustaría a los administradores, tiene el efecto de instituir la revocación.

Dicho esto, la utilización adecuada del JWT debería hacer que esto no sea un problema, ya que el usuario todavía tiene que proporcionar una cierta cantidad de información secreta a través de un canal cifrado y, como tal, ya debería ser "examinado" o controlado.

Cómo controlar la identidad del usuario dentro de los microservicios

No dejes a JWT solo

El simple hecho es que los JWT son una gran solución, especialmente cuando se usan en conjunto con algo como OAuth. Estos beneficios desaparecen rápidamente cuando se usan solos y, en muchos casos, pueden resultar en una peor seguridad general .

Dicho esto, adoptar las soluciones adecuadas puede mitigar muchas de estas amenazas, lo que da como resultado un sistema más seguro y eficiente. El primer paso para proteger su JWT es comprender lo que no es: un JWT es un método de codificación, no un método de cifrado o seguridad de transporte y, como tal, es solo una parte del rompecabezas.

¿Cuál es su mejor solución para proteger JWT? Háganos saber en la sección de comentarios a continuación.

Publicar un comentario

0 Comentarios