Resumen

  • El token expresa una delegación anterior, no necesariamente una política vigente.
  • La evidencia debe ligar validación, estado actual y horizonte de vigencia.

Imaginemos que un administrador retira un permiso y que una API sigue aceptando, solicitud tras solicitud y hasta su vencimiento, un token de portador emitido antes. La firma y la audiencia pueden ser correctas, y el plazo puede seguir vigente. Si el registro de auditoría etiqueta cada aceptación repetida como «autorizada», mezcla la validación de una credencial con una decisión actual de autorización.

RFC 6749 define el token de acceso como una credencial que representa alcance y duración. Puede ser opaco o autocontenido; por ello su posesión no revela si el servidor consultó estado vigente. RFC 7009 permite revocarlo, pero reconoce demoras de propagación. RFC 7662 permite consultar si está activo y recibir metadatos apropiados para el recurso. Una respuesta positiva almacenada en caché, sin embargo, vuelve a abrir la ventana de estado obsoleto.

La introspección no es obligatoria en toda implantación. active expresa la valoración del servidor de autorización para el recurso que consulta; no demuestra la identidad de una persona, la propiedad del dispositivo ni toda autorización definida por la política de negocio. Según la política, la revocación puede afectar tokens relacionados o la concesión original. Propagación, caché, tolerancia del reloj y dependencia del servidor forman el límite real.

Caducidad, revocación e introspección no son sinónimos. Un vencimiento corto limita la exposición; no prueba que la cuenta, el rol, el cliente o la política hayan permanecido aceptables. La introspección aporta control actual, pero su caché decide cuánto tiempo una respuesta anterior puede sustituir a otra nueva.

La validación local y la consulta de estado contestan preguntas distintas: la primera comprueba el token disponible y la segunda pregunta a una autoridad por su estado actual. Una operación de alto impacto necesita evidencia más reciente que una lectura ordinaria. Deben incluirse las cachés de autorización de pasarelas y aplicaciones y medirse toda la cadena: emisión, propagación de la revocación, validación local o introspección y decisión actual del servidor de recursos.

El registro de la decisión de autorización debe conservar la huella no secreta del token, emisor, cliente, sujeto pertinente, audiencia, alcances, horas de emisión y expiración, método de validación, estado de revocación o introspección, identificador de la política vigente, hora de decisión del servidor de recursos y duración máxima de la caché. Así separa la delegación original de la razón actual para aceptar la operación.