¡Deja de Usar JSON Web Tokens (JWTs) para Autorización!

Hola, y bienvenidos a esta charla relámpago sobre No uses JWT para autorización. Mi nombre es Sohan Maheshwar. Trabajo en una startup llamada AuthZ, y la historia detrás de esta charla es realmente divertida. Hace mucho tiempo, publiqué un video en YouTube llamado, bueno, No uses JWTs para autorización. Sí, sé que tengo la típica cara de YouTube en la miniatura, etcétera. Pero lo que pasó fue que aproximadamente una semana después de publicar este video, esto sucedió, alrededor de 35,000 vistas en solo una semana. Y resulta que no, ya sabes, a veces la gente en internet puede no ser tan amable porque recibí muchos comentarios como este sobre, ya sabes, llamándome un genio, pero creo que sarcásticamente. La gente diciendo, oye, no tengo idea de lo que estoy hablando. Algo sobre un mercado de JWT, que no estoy seguro de qué es eso. Cuestionando si leí el RFC para JWT, que admito es una lectura bastante aburrida. Y creo que este habla por sí mismo. Así que pensé en dar esta charla en una conferencia y ver si la gente realmente me dice esto tal vez en persona o en los comentarios. Pero aquí vamos. Y la idea es, no uses JWTs para autorización.

Para establecer el contexto, los JWTs o JSON Web Tokens son esencialmente un formato de intercambio de datos. En este formato, hay tres cosas. Hay un encabezado, una carga útil y una firma. Las dos cosas de las que no nos preocupamos demasiado para esta charla son el encabezado, ya sabes, algo sobre un tipo de algoritmo, etcétera, y la firma, que suele ser una firma criptográfica. Así que no nos enfoquemos en eso. La parte en la que quiero que te enfoques hoy es la carga útil. Y esta carga útil, nuevamente, tiene algunos datos y generalmente hay un nombre, un tiempo de expiración, que es cuando el token expira, un rol y también alcances.

Y aquí es donde las cosas se ponen interesantes porque cómo la gente ha usado JWT para autorización es en el alcance añadir cosas como admin o read o write, etcétera, y asociar eso con permisos para una persona en una aplicación. Así que digamos que tengo permisos de lectura y tú tienes permisos de escritura, eso se incluiría en el alcance y este token se pasaría cuando se crea un servicio. Ahora, curiosamente, este alcance ni siquiera es del JWT original o la especificación de JWT y en realidad proviene de una especificación diferente, que es la especificación de intercambio de tokens OAuth2. Así que, ya sabes, de alguna manera tal vez ni siquiera fue creado específicamente para esto para autorización y permisos, pero aquí estamos usándolo bastante regularmente.

La suposición subyacente al usar esto es que los permisos no cambian durante la vida útil de un token. Y eso es muy, muy falso, ¿verdad? Eso no es absolutamente cierto, especialmente en los sistemas complejos que estamos construyendo hoy. Así que voy a darte tres razones por las que no deberías usar JWTs para tu autorización. Y nuevamente, cuando digo autorización, me refiero a permisos detallados. Problema número uno, y este es el mayor problema con el uso de JWTs y autorización es que no hay una manera significativa de revocar un token una vez que está en circulación. Así que digamos que añades un montón de alcances en un token y lo envías en circulación y algo cambia como que un usuario es eliminado de una organización.

Tal vez su rol se degrade de admin a viewer. O tal vez simplemente han sido eliminados de un cierto archivo. No hay una manera significativa de revertir eso o revocar este token una vez que está fuera. Esencialmente tienes que esperar hasta la expiración. Y por supuesto, puedes pensar en cosas como tokens de actualización, etc. Pero nuevamente, eso no es una gran experiencia de usuario para aquellos cuyos roles o usuarios o lo que sea han permanecido igual. Estás enviando un token de actualización para un montón de personas.

Así que la idea es que un JWT es autónomo, no tiene estado, y no estás verificando el estado de la realidad con la autoridad centralizada. Una vez que ese token se envía, la realidad cambia, pero la información en ese token no cambia. Y esto en realidad tiene un nombre y se llama el problema del nuevo enemigo. Así que te lo describiré. Tienes a Kara aquí que tiene acceso a planes secretos, y también Lex. Pero Lex es un villano. Así que Kara elimina los permisos de lectura de Lex de este archivo. Aquí está la parte importante. Kara añade nuevos secretos. Así que en este punto, Lex no debería poder acceder a este nuevo secreto. Pero debido al hecho de que Lex tiene permisos en este token, Lex intenta leer este documento y puede verlo. Y el caos se desata.

Así que este es el problema del nuevo enemigo, que se describe en un documento técnico escrito por Google llamado Google Zanzibar. Ahora, este documento fue publicado en 2019, y documenta cómo funciona el sistema de autorización interno de Google a través de maps, YouTube sheets, etc. Así que hay una buena posibilidad de que lo hayas usado en algún momento. Volveremos a esto en un momento. El problema número dos es que los alcances realmente no escalan. Así que incluso si tu caso de uso tiene algo donde dices, está bien, las cosas no cambian muy a menudo. No necesito revocarlo.

No puedes escalar tus alcances a permisos detallados. Los alcances son demasiado amplios. Por ejemplo, Profile Admin es, ¿de qué datos estamos hablando? ¿Es el perfil del usuario actual? ¿Es todo el sitio web? Es muy difícil decir esto, y esto ha plagado la REST API de GitHub durante muchos años, si alguna vez la has usado. En nuestra época, realmente buscamos una autorización detallada.

Así que un usuario como tú podría tener acceso a millones de objetos de software, donde en realidad, en un sistema de producción, probablemente quieras limitar tu acceso solo a las cosas en las que estás trabajando o que están relacionadas. Así que, por ejemplo, issue slash AuthSet slash SPICEdb slash algo slash author. Puedes dar acceso solo a eso en lugar de simplemente emitir author para cualquier cosa. Y con alcances y con JWTs, no puedes hacer esto. Solo puedes decir, agrega más alcances, agrega más tokens, pero solo estás pasando este enorme token de un lado a otro. Y la mayoría de los servidores y la especificación de JWT ni siquiera lo soportan. Quiero decir, puedes simplemente buscar esto en Google y verás a personas enfrentando este problema.

Así que no es una gran idea. Y el problema número tres, el problema final es, nuevamente, en un entorno complejo como un sistema empresarial no puedes predecir permisos. Esencialmente, un JWT se crea en un punto de entrada de solicitud, y simplemente va río abajo. Pero para eso, necesita conocer cada servicio río abajo y qué permisos se necesitan, ya sabes, aquí y allá. Y con una arquitectura de microservicios, que es como muchos de nosotros hacemos arquitectura y codificación hoy en día en lugar de monolitos, esto en realidad es imposible. Y la gente ha resuelto esto diciendo, ya sabes qué, voy a sobreprovisionar ligeramente un token para que cada servicio río abajo tenga acceso o pueda hacer lo que quiera. Pero esto es muy malo.

Por favor, no hagas esto porque básicamente estás dando permisos adicionales que se filtran río abajo. Tu superficie de ataque está aumentando y corres el riesgo, ya sabes, de escalada de privilegios. Tal vez un servicio o algo está sobreprivilegiado y alguien con intenciones maliciosas puede entrar allí y hacer cosas malas. Y francamente, este problema se va a agravar con cosas como agentes de IA, donde realmente quieres limitar lo que tu agente de IA puede hacer. Y nuevamente, JWTs y pasar un token con alcances no es la forma de hacerlo.

Hace unos años, en realidad hubo una solución para este mismo problema en la forma de algo llamado un Macaroon, que creo que es un juego de palabras con la palabra cookie. Y nuevamente, hay un documento técnico en Google sobre macaroons. Es en realidad una pieza de tecnología bastante genial donde, ya sabes, es más flexible y utiliza un modelo de alcance reducido o de atenuación donde a cada servicio se le da lo que necesita para, ya sabes, realizar una tarea. Así que estás atenuando como ese servicio. El problema era que era muy complejo de implementar. Es difícil de adoptar. Nuevamente, busca en YouTube, hay suficientes charlas sobre cómo los macaroons son geniales, pero en realidad muy difíciles de implementar.

Todo esto para decir que el control de acceso es muy complejo. Nuestros sistemas hoy en día no son los mismos que hace 10-15 años. Son vastos. Hablan con otros sistemas y son complejos y el control de acceso se vuelve difícil. Y no solo lo digo yo. Si alguna vez has oído hablar de OWASP o Open Worldwide App Security Project, es un organismo de la industria. Hacen una lista de los 10 principales, los 10 principales riesgos de seguridad para aplicaciones web. Y esta lista sale cada cuatro años. Las dos últimas listas han sido encabezadas por el control de acceso roto. Así que este es el mayor riesgo para una aplicación web. Increíblemente, el 100%, nuevamente, el 100% de las aplicaciones probadas tenían problemas de control de acceso roto. Entonces, ¿cómo lo solucionas?

Hay dos tipos principales, diría yo, de un sistema moderno de autorización. El primero es el que mencioné anteriormente, que es el sistema Zanzibar de Google, donde en lugar de poner roles o reducir todo a un atributo, haces algo llamado Reback o control de acceso basado en relaciones, donde todo está en forma de una relación. Así que un usuario tiene una relación con un archivo, un archivo tiene una relación con una carpeta, y tú calculas permisos basados en eso. Hay tres que puedo recomendar de su código abierto, como SpiceDB, OpenFG, y Permafy. Trabajo en SpiceDB, así que, por supuesto, voy a tener un sesgo hacia eso.

Y el segundo tipo es un punto de decisión de política o un motor de políticas, donde tu autorización es un problema lógico que se resuelve evaluando una política. Así que si algo pasa esa política, obtienes un sí. Y nuevamente, algunos populares incluyen Open Policy Agent, CDER, y CERBOS. Diría que si tienes algo que tiene muchos datos y jerarquías y cambia frecuentemente, incluyendo cosas como AI y agentes, etcétera, opta por un sistema Zanzibar. Si quieres algo donde toda la información esté en la propia llamada de solicitud, iría por un motor de políticas.

La idea, por supuesto, es que estás intercambiando algo que es relativamente simple, como un JWT, y que es sin estado, por algo que podría ser un poco más complejo de implementar al principio, pero estás obteniendo corrección, flexibilidad y, lo más importante, seguridad, lo cual no puedo enfatizar lo suficiente, es tan importante ahora mismo. Hay momentos en los que puedes usar JWTs cuando tienes una concesión no revocable de una sola vez, como por ejemplo un enlace de verificación de correo electrónico o un enlace de descarga que expira en un día o lo que sea. Pero para casos de uso en producción como una decisión de autorización de una aplicación de larga duración, o cualquier cosa de grano fino, evitaría absolutamente usar JWTs.

Ahora sé que tienes muchas preguntas sobre cosas como tokens de actualización y almacenar cosas localmente y todo eso. No tengo tiempo para cubrir eso, pero ese primer enlace que puse allí, que tiene este diagrama de flujo, cubrirá todas tus preguntas sobre el uso de JWTs para permisos de grano fino. Un par de otras cosas que también puedes leer para aprender más sobre este tema. Me encantaría conectarme contigo en LinkedIn y espero que disfrutes el resto de la conferencia. Y recuerda, no uses JWTs para permisos de grano fino. Disfruta y que tengas un gran día. Adiós.