¡Deja de usar JSON Web Tokens (JWTs) para autorización!

Hola, y bienvenidos a esta charla relámpago sobre no usar JWT para autorización. Mi nombre es Sohan Maheshwar. Trabajo en una startup llamada AuthZed. Y la historia detrás de esta charla es realmente bastante divertida.

Hace algún tiempo, publiqué un video en YouTube llamado Don't Use JWTs for Authorization. Sí, sé que tengo la típica cara de YouTube en la miniatura, etc. Pero lo que pasó fue que aproximadamente una semana después de publicar este video, esto sucedió. Aproximadamente 35,000 vistas en solo una semana y resulta que a veces la gente en internet puede ser no tan amable porque recibí muchos comentarios como este llamándome un genio, pero creo que de manera sarcástica.

La gente diciendo, oye, no tengo idea de lo que estoy hablando, algo sobre un mercado de JWT, lo cual no estoy seguro de qué es. Cuestionando si he leído el RSC para JWT, que admito es una lectura bastante aburrida. Y este creo que 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. Así que la idea es no usar 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, algunas cosas sobre un tipo de algoritmo, etc. y la firma, que suele ser una firma criptográfica. No nos centremos en eso. La parte en la que quiero que te concentres 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 scopes. Y aquí es donde las cosas se ponen interesantes porque cómo la gente ha usado JWT para autorización es en el scope añadir cosas como admin o read o write, etc. y asociarlo 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 scope y este token se pasaría cuando se crea un servicio.

Ahora, curiosamente, este scope 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 OR2. 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 detrás de usar esto es que los permisos no cambian durante la vida útil de un token. Y eso es muy, muy falso, ¿verdad? Eso es absolutamente no 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 de nuevo, cuando digo autorización, me refiero a permisos detallados.

Problema número uno y este es el mayor problema al usar JWTs en 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 scopes en un token y lo envías al mundo y algo cambia como que un usuario es removido de una organización. Tal vez su rol se degrada de admin a viewer o tal vez simplemente han sido removidos de un cierto archivo. No hay una manera significativa de retractarse o revocar este token una vez que está fuera. Esencialmente tienes que esperar hasta que expire.

Y por supuesto, puedes pensar en cosas como refresh tokens, etc. Pero de nuevo, 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 refresh token para un montón de personas. Así que la idea es que un JWT es autónomo. Es sin estado y no estás verificando el estado de la realidad con la autoridad centralizada. Una vez que ese token es enviado, 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 lector 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 a esto, ya sabes, el hecho de que Lex tiene permisos en este token, Lex intenta leer este documento y puede verlo. Y ya sabes, 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 scopes 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 scopes a permisos detallados. Los scopes son demasiado amplios. Así que, por ejemplo, admin de perfil, ¿de qué datos estamos hablando? ¿Es el perfil del usuario actual? ¿Es todo el sitio web? Es muy difícil decir esto. Esto en realidad ha plagado la API REST de GitHub durante muchos años, si alguna vez la usaste. En nuestra época, realmente buscamos 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 están relacionadas.

Por ejemplo, issue//authset//spice-tv//algo//autor. Puedes dar acceso solo a eso en lugar de simplemente emitir autor para cualquier cosa. Y con scopes y con JWTs, no puedes hacer esto. Solo puedes decir añade más scopes, añade más tokens, pero solo estás pasando este enorme token de arriba a abajo, y la mayoría de los servidores y la especificación de JWT ni siquiera lo soportan. Solo puedes buscar esto en Google y verás a personas enfrentando este problema. Así que no es una gran idea. Y el número tres, el problema final es, de nuevo, 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 hacia abajo. Pero para eso, necesita conocer cada servicio downstream 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 downstream 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 downstream. 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, los JWTs y pasar un token con scopes 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 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 soy solo yo quien lo dice. Si alguna vez has oído hablar de OWASP o Open Worldwide App Security Project, es una empresa de la industria que hace una lista de los 10 principales riesgos de seguridad para aplicaciones web.

Y esta lista se publica 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? Bueno, diría que mires los métodos de autorización modernos y OWASP ellos mismos recomiendan esto.

Hay dos tipos principales, diría yo, de un sistema de autorización moderno. El primero es lo que mencioné anteriormente, que es un sistema Google Xanthabar, 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. Un usuario tiene una relación con un archivo, un archivo tiene una relación con una carpeta, y calculas permisos basados en eso. Hay tres que puedo recomendar de su código abierto, como SpiceDB, OpenFG, y Permify.

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 de lógica 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, Cedar, y Serbos. Diría que si tienes algo que tiene muchos datos y jerarquías y cambia frecuentemente, incluyendo cosas como IA y agentes, etcétera, opta por un sistema Xanthabar. Si quieres algo donde toda la información esté en la propia llamada de solicitud, iría por un motor de políticas.