Resumen

  • El IESG aprobó el 24 de agosto de 2026 la revisión 10 de draft-ietf-oauth-rfc8725bis como Best Current Practice. Al cierre de evidencias seguía siendo un Internet-Draft en la cola del RFC Editor; cuando se publique, sustituirá RFC 8725 y actualizará RFC 7519.
  • La defensa central consiste en que los validadores de clases distintas de JWT sean mutuamente excluyentes. Una firma correcta no autoriza por sí sola: todavía deben coincidir el tipo, el emisor, la audiencia, los claims, las cabeceras, el algoritmo, la clave y el contexto de uso.

Un token de alarma ante la puerta de pagos

Pensemos en una plataforma que recibe Security Event Tokens para notificar cambios de cuenta. La misma organización tiene una API de pagos que consume tokens de acceso. Ambos servicios confían en el mismo emisor y descargan las mismas claves. Un token de evento llega a la API, pasa la verificación de firma y el componente común devuelve un resultado positivo.

No hubo falsificación. Hubo sustitución de autoridad.

El ejemplo es una prueba mental, no un incidente atribuido. Expone la confusión entre JWT que la revisión quiere impedir: un objeto emitido con una finalidad se presenta en un contexto diseñado para otra. Si el receptor solo pregunta si la firma es buena, convierte una declaración auténtica en un permiso que el emisor nunca otorgó.

La solución no es decorar el mismo validador con más criptografía. Cada clase de token necesita un perfil cerrado. El receptor de eventos y la API de pagos deben rechazar los objetos del otro aunque compartan formato, emisor, clave y algunos nombres de claim.

La noticia normativa tiene varias fechas

El anuncio del IESG registra la aprobación de “JSON Web Token Best Current Practices” el 24 de agosto a las 18:02 UTC. Se trata de la revisión 10 del trabajo del grupo OAuth y su destino declarado es Best Current Practice.

El 28 de agosto, el Datatracker aún mostraba un Internet-Draft activo, fechado el día 21, actualizado el 25 y con caducidad el 22 de febrero de 2027. El estado del IESG era RFC Ed Queue. El RFC Editor esperaba una referencia todavía no recibida. IANA indicaba que no hacían falta nuevas acciones de registro, aunque el seguimiento continuaba en curso.

Por tanto, hay una decisión aprobada, pero aún no un RFC publicado ni evidencia de adopción. Según el encabezado del documento, su publicación hará obsoleto RFC 8725 y modificará la especificación base de JWT, RFC 7519. Mantener esos estados separados evita convertir una aprobación en una afirmación prematura sobre el software desplegado.

Cuatro pruebas antes de una autorización

JWT organiza claims; no describe una única protección. Puede viajar como JWS firmado, JWE cifrado, objeto anidado o, si una aplicación lo autoriza expresamente, JWT sin seguridad. La serialización compacta de base64url y puntos tampoco equivale a todas las serializaciones JSON definidas por JOSE.

Un receptor disciplinado emite cuatro veredictos distintos:

  1. el objeto tiene exactamente la forma admitida por este endpoint;
  2. la firma o el cifrado autenticado se verifica con un algoritmo permitido y la clave correcta;
  3. el objeto pertenece a la clase de token que este consumidor conoce;
  4. sus claims autorizan esta acción, ahora, para este emisor, audiencia y sujeto.

Descifrar un JWE no verifica automáticamente un JWT interior. Aceptar una forma compacta no establece confianza. Verificar un JWS no vuelve universales sus claims. Cada transición necesita su propia evidencia.

typ sirve para excluir, no para adornar

La nueva guía recomienda tipado explícito cuando pueda existir confusión. RFC 8417 da a los Security Event Tokens un tipo identificable. El valor genérico JWT, en cambio, solo repite que el contenedor es JWT; no identifica el contrato de aplicación.

La cabecera por sí sola no basta. Los validadores de clases diferentes deben aceptar conjuntos mutuamente excluyentes. La separación puede establecerse mediante tipos explícitos, claims o valores obligatorios distintos, cabeceras protegidas, claves, audiencias o emisores propios.

RFC 9068 perfila los tokens de acceso OAuth; RFC 8417 perfila los eventos de seguridad. Los dos pueden estar firmados legítimamente y, aun así, no ser intercambiables. El consumidor debe elegir el perfil antes de conceder significado operativo a los claims.

La transición puede ser gradual. Muchos tokens heredados carecen de typ, por lo que exigirlo de inmediato puede cortar servicio. Una fase inicial compatible rechaza cualquier valor presente que contradiga el esperado, contabiliza omisiones y coordina después la obligatoriedad con emisores y consumidores.

El contexto no se hereda de la empresa

El emisor expresa quién formula las declaraciones. La audiencia limita para quién las formula. Ambos deben validarse según el perfil antes de que los claims alteren permisos o rutas.

Que dos aplicaciones pertenezcan a la misma compañía no las convierte en una sola audiencia. Un token para el servicio A no puede presentarse en B solo porque ambos dependen del mismo proveedor de identidad. La administración común no elimina las fronteras de confianza.

Tampoco sub posee un significado universal. Puede nombrar a una persona, a un cliente o al sujeto de un evento. El nombre del campo se mantiene; la clase de token determina su semántica.

El objeto no elige cómo se comprueba

El receptor debe controlar una lista explícita de algoritmos admitidos. alg es un dato que se contrasta, no una instrucción para escoger la política. La revisión insiste además en que una clave se use con exactamente un algoritmo, evitando reinterpretaciones incompatibles del mismo material.

Las cabeceras de selección de claves también reciben datos hostiles. kid, jku y x5u pueden guiar búsquedas o descargas. Sin restricciones, abren inyección o peticiones desde el servidor a destinos arbitrarios. Que una cabecera esté dentro de un objeto firmado no concede al emisor acceso de red ilimitado.

La revisión añade controles sobre el coste mínimo del cifrado basado en contraseña, límites de descompresión para JWE y algoritmos completamente especificados como los de RFC 9864. Son defensas frente al agotamiento de recursos y la ambigüedad, no solo frente a firmas falsas.

Qué debe demostrar un registro de aceptación

La cadena empieza en los bytes recibidos y la serialización. Continúa por el endpoint, el perfil esperado, las cabeceras protegidas, el algoritmo permitido, la clave resuelta, el resultado criptográfico, el tipo, el emisor, la audiencia, los claims y tiempos exigidos, el estado de repetición o revocación, la decisión de política y el efecto final.

Un log que diga simplemente «JWT válido» borra la distinción que luego necesita un investigador. No prueba qué clase se esperaba, qué audiencia se comparó ni si la decisión produjo una acción.

Aquí la primacía del código en funcionamiento es práctica: el texto fija un invariante mínimo, pero la prueba decisiva es que el consumidor real rechace una sustitución y que no ocurra efecto alguno aguas abajo.

Fuentes