Resumen

  • active: true en RFC 9767 reúne condiciones de emisión, vigencia, revocación, prueba, audiencia y acceso para el servidor de recursos que formula la consulta.
  • El servidor de autorización contesta sobre el token; el servidor de recursos valida la presentación actual, aplica su política y elige la respuesta concreta.
  • Una operación auditable separa cuatro recibos: introspección, prueba del mensaje, decisión local y efecto, sin ocultar la edad de caché ni los tokens derivados.

La pregunta detrás del sí

Una aplicación presenta un token a un servidor de recursos. Este consulta al servidor de autorización y recibe un booleano positivo. Si el registro sólo conserva ese dato, parece que la autoridad central ordenó ejecutar la operación. Pero la consulta real contenía más cosas: qué RS preguntó, cómo se demostró la posesión, qué acceso mínimo necesitaba y cuándo se obtuvo la respuesta.

RFC 9767 amplía GNAP para despliegues en los que AS y RS están desacoplados. El protocolo base explica la relación entre cliente y AS; esta extensión ofrece descubrimiento, introspección y registro de recursos del lado del RS. Compartir una interfaz no convierte dos funciones en una sola autoridad.

El RS firma su consulta con su propia clave, no con la clave del cliente ni con la del token. Envía el valor presentado, la identidad del RS y, de forma recomendada, el método de prueba. Puede añadir el conjunto mínimo de acceso que exige la petición. El AS tiene que considerar todos los parámetros. Si no comprende uno, no puede declarar activo el token.

Por eso «activo» no es una pegatina permanente. Un token puede ser adecuado en RS1 y no en RS2; válido para leer pero insuficiente para escribir; vigente en el reloj y, aun así, mal presentado. La respuesta vive dentro del contexto que la produjo.

La conjunción que cabe en un bit

Para responder true, el token debe proceder del AS que procesa la consulta, no estar revocado ni vencido, corresponder al método de prueba indicado, ser apropiado para el RS identificado y cubrir el acceso solicitado cuando éste se especifica.

False no identifica una causa única. También representa que el AS no puede determinar el estado, por ejemplo porque no encuentra el token. Por diseño, los demás campos se omiten. Un sistema que etiqueta todo falso como «revocado» inventa una certeza que la interfaz no proporciona.

El positivo tiene el límite inverso. No certifica la intención humana, la corrección del cuerpo, la existencia actual del objeto, una regla antifraude, una cuota, una obligación legal o la entrega del servicio. Tampoco dice que el RS haya aceptado la petición. Es un veredicto sobre el artefacto bajo condiciones declaradas.

La respuesta activa puede incluir derechos, clave, marcas y tiempos. Los derechos pueden filtrarse para ese RS e incluso ser una lista vacía. Nunca debe devolver el valor del token. Así, la introspección puede evitar que un servicio reciba información que sólo necesita otro, aunque la selección también significa que dos RS no ven necesariamente la misma descripción.

La última palabra está en el recurso

RFC 9767 deja una frase que debería aparecer en todo diseño: el RS decide el curso de acción. Si los derechos no bastan, puede devolver un error o una versión pública del recurso. La respuesta final queda a su criterio.

Eso no elimina controles. Ubica el control donde existe el objeto y puede ejecutarse la acción. El AS conoce el grant, el emisor y el estado del token. El RS conoce endpoint, método, estado interno, límites de negocio, política de exposición y alternativas posibles.

La decisión local necesita trazabilidad. Hay que guardar recurso y operación, derechos considerados, versión de política, controles adicionales, identidad del software y salida elegida. Una respuesta pública después de un token insuficiente no es un acceso privado autorizado. Un error HTTP tampoco demuestra que nada cambiara: una transacción pudo confirmarse antes de perderse la respuesta.

El efecto requiere su propio recibo. Para una escritura, puede ser el identificador del commit o del cambio. Para una lectura, la clase de contenido realmente entregado. Para una llamada aguas abajo, la confirmación del siguiente servicio. El booleano del AS no observa esos hechos.

Probar la llave no valida el token

Los tokens ligados a clave añaden una defensa y una posible confusión. La prueba demuestra que la petición actual posee o usa la clave esperada según el método elegido. No amplía derechos ni repara un token revocado. A la vez, un token activo no valida automáticamente la firma, nonce, destino o contenido de este mensaje.

RFC 9767 pide comprobar la prueba de manera independiente en cada solicitud al RS. No se debe tomar la validación de un mensaje y aplicarla al siguiente. Las firmas HTTP, DPoP y los tokens vinculados a certificado ofrecen técnicas diferentes; todas necesitan unir token, clave, método, destino y mensaje en el instante de uso.

La telemetría debe reflejar esas dos validaciones. Una fila para la introspección, con contexto y tiempo; otra para la prueba actual, con componentes cubiertos, clave, algoritmo, datos de frescura y resultado. El campo genérico «authorized=true» hace imposible distinguirlas tras un incidente.

El caché convierte el tiempo en política

Consultar al AS en cada operación añade latencia y dependencia. El RS puede guardar un resultado de validación. La ganancia es rendimiento; la pérdida es actualidad. Mientras usa un positivo antiguo, puede aceptar un token ya revocado.

El TTL no es un detalle neutro. Expresa cuánto tiempo acepta el operador del RS sustituir el estado presente del AS por una fotografía. Esa decisión depende de la acción: listar información pública, leer datos privados y ordenar un pago no tienen por qué compartir tolerancia.

La clave del caché también debe conservar el contexto. Indexar sólo por token puede reutilizar para otro RS o acceso una respuesta que nunca cubrió esa pregunta. Un negativo prolongado puede ocultar una recuperación porque false agrupa múltiples causas e incertidumbre.

RFC 7009 describe la revocación OAuth, pero una solicitud de revocación no demuestra que cada caché dejó de servir el positivo. RFC 9767 menciona señalización proactiva y la deja fuera de alcance. El cierre operativo requiere evento de invalidación, cachés afectados y una decisión posterior que demuestre el cambio.

Privacidad y mínima divulgación

La introspección puede filtrar claims por RS. Es útil cuando un token válido para varias APIs contiene atributos sensibles: el servicio que no necesita un identificador médico no debería verlo. Pero el canal vivo revela al AS dónde y cuándo se utiliza un token.

Un token estructurado permite validación local y reduce esa observación central, aunque puede distribuir más datos y retardar la noticia de revocación. Uno opaco concentra el conocimiento en el AS y exige llamadas. El modelo mixto puede separar clases de información. La elección no es «privado» o «no privado»; es qué parte aprende qué dato, con qué frescura y retención.

También importa el tipo de clave. Entregar una clave pública para verificar una prueba asimétrica no permite crear la firma privada. Compartir una clave simétrica con el RS le da material para fabricar otra presentación. El riesgo de exfiltración y reutilización cambia aunque ambos casos se llamen sender-constrained.

El identificador de referencia de recursos debe permanecer opaco. Si el AS codifica estructura reconocible, cliente y RS terminan analizándola y acoplándose a detalles accidentales. Valores aleatorios o cifrados mantienen el identificador como referencia de coordinación, no como autorización autosuficiente.

Derivar no significa conservar el efecto

En una cadena, RS1 puede necesitar llamar a RS2. Reutilizar el token del cliente expone bearer secrets y mezcla actores. RFC 9767 permite pedir un token derivado usando existing_access_token; RS1 se identifica como cliente con su propia clave y firma una nueva petición al AS.

El AS verifica que el token entrante era adecuado para RS1 y puede emitir un token más estrecho, dirigido a RS2 y ligado a RS1. Si hay otro salto, el proceso puede repetirse. Esta forma se parece al intercambio de tokens OAuth en que cada artefacto nuevo obliga a precisar actor, sujeto, audiencia y derechos.

La cadena criptográfica no es una cadena de resultados. El token de RS2 no prueba que RS1 interpretó bien la orden, que RS2 ejecutó la acción ni que la respuesta regresó al cliente. Cada tramo necesita custodiar petición, derivación, presentación, decisión y efecto.

Cuatro recibos, no una luz verde

El diseño operativo puede resumirse en cuatro objetos. Recibo de introspección: pregunta completa, RS firmante, respuesta, claims, tiempo y caché. Recibo de prueba: mensaje exacto, clave, algoritmo y frescura. Recibo de decisión: recurso, política local y salida. Recibo de efecto: cambio confirmado, respuesta entregada o compensación.

Las pruebas negativas deben separar fallos: token correcto en audiencia incorrecta; acceso mínimo no cubierto; parámetro desconocido; prueba repetida; caché positivo después de revocar; acceso filtrado vacío; commit sin respuesta; token entrante reutilizado en RS2. Un sistema robusto no adivina la siguiente etapa cuando falta evidencia.

Fuentes