Resumen

  • RFC 9701 protege la respuesta de introspección OAuth con un JWT firmado y, opcionalmente, cifrado; su envoltura identifica al emisor, al servidor receptor y el momento de creación, mientras el objeto anidado describe el token.
  • Verificar la firma solo abre la siguiente pregunta: hay que comprobar tipo, audiencia, frescura, estado y alcance anidados, base de divulgación, prueba antirrepetición, regla local y resultado de la operación.

El primer aud dice: «esta respuesta fue creada para este servidor de recursos». El segundo puede decir: «el token inspeccionado está destinado a esta API». Parecen redundantes porque usan el mismo nombre. En RFC 9701 forman una barrera contra una confusión más profunda: la respuesta acerca de una credencial no es la credencial.

RFC 7662 permite consultar el estado de un token OAuth y obtener un objeto JSON. RFC 9701 introduce un formato JWT cuando el destinatario necesita atribuir esa información de forma criptográfica al servidor de autorización. La mejora preserva quién dijo qué y para quién. No decide qué operación debe autorizar el servidor de recursos.

El destinatario de los datos también necesita autorización

El servidor de autorización debe identificar, autenticar y autorizar al servidor de recursos que llama al endpoint. No basta con que alguien conozca la URL ni con que establezca TLS. El servicio debe saber quién pregunta, si ese servidor es audiencia del token y qué datos puede recibir.

Una opción es registrar al servidor como cliente mediante RFC 7591, con credenciales y claves específicas. El estándar no impone una única base de datos, pero exige una consecuencia clara: las credenciales del servidor de recursos deben limitarse a las llamadas que necesita.

Si el token es inválido, expiró, fue revocado o no corresponde a la audiencia solicitante, la respuesta anidada lleva active:false y no incluye los demás miembros. Así, una respuesta negativa no se convierte en una fuente de identidad, alcance o cronología para un tercero.

Cuando el token está activo para ese servidor, el alcance debería reducirse a lo relevante. Los datos personales obedecen una política por destinatario y una base jurídica. El token puede ser el mismo y, aun así, las respuestas correctas pueden ser diferentes.

La envoltura no debe mezclarse con el contenido

La negociación usa Accept: application/token-introspection+jwt; la respuesta declara ese tipo y su cabecera JWT fija typ: token-introspection+jwt. Los claims superiores obligatorios son iss, aud, iat y token_introspection.

El iss superior atribuye la respuesta. El aud superior restringe su consumo. El iat superior fecha la declaración. Dentro de token_introspection, sub, scope, exp, aud, iat y extensiones describen el token de acceso. Incluso dos marcas temporales correctas pueden tener edades y usos distintos.

Por eso el texto desaconseja sub y exp en el nivel superior. El JWT de introspección no es una representación alternativa del token inspeccionado y no debe circular como token de acceso. Los registros de parámetros OAuth, claims JWT y tipo de medio coordinan nombres; la separación efectiva depende del código.

Firmar, cifrar y decidir son tres trabajos

La respuesta puede ir firmada o firmada y después cifrada como JWT anidado. JWS conserva integridad y atribución; JWE añade confidencialidad; JWT define la composición. Ninguno selecciona automáticamente emisores confiables, claves vigentes, algoritmos aceptables o edades máximas.

RFC 9701 incorpora metadatos de algoritmo. El servidor de autorización puede publicar capacidades según RFC 8414, y el servidor de recursos puede registrar claves de cifrado. La lista anunciada no prueba qué opción usó una respuesta concreta. El recibo operativo debe nombrar el algoritmo, la clave ligada al emisor, la versión de configuración y cada comparación realizada.

El cifrado tampoco corrige una decisión de audiencia equivocada. Si el servidor de autorización cifra para un recurso que nunca debió recibir esos datos, la confidencialidad frente a terceros funciona mientras la autorización de divulgación falla.

Una respuesta puede hacerse pasar por token

Un token de acceso JWT y una respuesta de introspección comparten la gramática compacta, firmas y claims familiares. Un validador genérico puede aceptar la respuesta como credencial si solo pregunta «¿la firma es válida?». RFC 9701 usa typ y el objeto anidado para impedir esa sustitución; RFC 8725 exige perfiles de validación explícitos y mutuamente exclusivos.

La defensa real exige que el endpoint de acceso acepte únicamente su perfil: tipo correcto, claims mínimos, emisor, audiencia, algoritmos y semántica esperada. Desencriptar con éxito no cambia el tipo del contenido. Un objeto auténtico puede seguir estando en el canal equivocado.

La firma de introspección tampoco sender-constrains el token. RFC 9701 remite a RFC 9700 para mitigar repetición. La prueba de posesión, la vinculación a la solicitud y la audiencia del token deben verificarse por separado. Saber que un token estaba activo no demuestra que este presentador pueda usarlo.

active:true es una fotografía con fecha

El iat superior permite medir la edad. No crea una política universal de caché. Un token activo al emitir la respuesta puede revocarse, expirar o perder alcance antes de la operación. La firma seguirá verificando una verdad histórica, aunque la evidencia sea demasiado antigua para una decisión actual.

Cada clase de operación necesita un límite de frescura. Las decisiones de alto impacto pueden exigir una introspección nueva. Si un sistema solo mide disponibilidad y latencia, tenderá a conservar respuestas más tiempo y convertirá la optimización en autorización obsoleta.

Después viene la política local. El alcance write no desbloquea por sí mismo un expediente, no supera un límite económico ni satisface una aprobación reforzada. El servidor de recursos produce allow o deny con su propia versión de regla. La ejecución añade otro recibo: una autorización seguida de un error no es un cambio realizado.

La consulta también revela actividad

La respuesta puede transportar información personal. RFC 9701 exige una base legal y control por destinatario. El cifrado protege bytes; no legitima una recopilación excesiva ni gobierna el uso posterior. RFC 9325 fortalece TLS, pero tampoco minimiza los claims.

Además, la solicitud informa al servidor de autorización de que el cliente, y quizá el usuario, está usando el servidor de recursos. Si esa observación no es aceptable, debe elegirse otro modo de trasladar los datos del token. La introspección es también una decisión de arquitectura de privacidad.

El expediente completo debe enlazar identificador protegido del token, operación, servidor solicitante, autenticación, TLS, hash de respuesta, typ, clave, firma, descifrado, claims de envoltura, claims anidados, base de divulgación, control antirrepetición, política local y efecto durable.

La especificación inicial mínima de Lu Heng deja el vocabulario y la estructura en la capa común y conserva la confianza, frescura, privacidad y autorización como decisiones locales visibles. Las capas de realidad separan registro, bytes, firma, estado reportado, veredicto y resultado. La primacía del código en ejecución exige la traza de este verificador y este enforcement, no una declaración abstracta de compatibilidad.

Fuentes