Resumen

  • La RFC 7662 permite que un recurso protegido consulte al servidor de autorización el estado actual de un token y reciba atributos pertinentes para ese recurso.
  • active: true expresa una conclusión real sobre la validez del token, no el permiso para una operación concreta ni la constancia de que la aplicación la ejecutó.
  • El caché reduce carga y latencia a cambio de actualidad; por eso el estado del token, la decisión local y el resultado deben conservarse como pruebas distintas.

El alcance exacto de una buena noticia

La introspección de tokens existe porque no todos los servidores de recursos pueden resolver por sí solos la validez de lo que reciben. Un token puede ser opaco, su revocación puede residir en otro sistema o la política de emisión puede haber cambiado. El recurso lo presenta al endpoint de introspección y obtiene un objeto cuya única propiedad obligatoria es active. Si el valor es verdadero, pueden acompañarlo el alcance, el cliente, el sujeto, el tipo de token, sus tiempos, audiencia y emisor.

La palabra tiene contenido normativo. La RFC 7662 describe como activo, por regla general, un token emitido por ese servidor de autorización, no revocado y situado dentro de su intervalo temporal. El servidor debe efectuar las comprobaciones aplicables: expiración, instante anterior al cual no puede usarse, revocación, firma y posibilidad de empleo en el recurso protegido que pregunta. Es una respuesta mucho más valiosa que un simple código HTTP correcto.

Precisamente por eso conviene no deformarla. El servidor de autorización conoce el ciclo del token; no necesariamente conoce el estado de cada objeto de negocio. No sabe si una cuenta pertenece a otro cliente, si un expediente está bloqueado, si se agotó un cupo o si una versión nueva volvió inválida la modificación propuesta. Esas reglas viven en el recurso y en la aplicación.

Un token activo puede, entonces, ser una credencial aceptable y aun así no bastar para esta solicitud. La introspección elimina incertidumbre sobre un plano. No convierte todos los demás controles en trámites redundantes.

La frontera de Richer separa dos autoridades

Justin Richer figura como autor de la RFC 7662, un documento Standards Track de la IETF. La atribución importa, pero también su límite: el texto forma parte de un proceso de estandarización colectivo. No otorga a Richer control personal sobre las implementaciones ni le adjudica en solitario cada idea de OAuth.

La interfaz que describe enlaza dos centros de conocimiento. El servidor de autorización puede hablar con autoridad sobre emisión, vigencia, revocación y datos asociados al token. El servidor de recursos puede hablar sobre el método solicitado, el objeto afectado y las condiciones locales. Que el segundo consulte al primero no le transfiere la responsabilidad sobre su política.

La arquitectura básica de OAuth ya preserva esa división. El cliente presenta un token de acceso al servidor de recursos; este valida el token y atiende la petición cuando se cumplen sus condiciones. La RFC 6750 explica ese recorrido para tokens al portador. La introspección normaliza una vía de validación, pero no escribe las reglas que relacionan un alcance con una operación de la aplicación.

Supongamos que vuelve un alcance de escritura. El recurso todavía puede exigir que el sujeto y el propietario coincidan, que la llamada llegue desde un contexto aprobado, que no exista una retención legal o que la suma esté por debajo de un umbral. Un registro que solo diga «autorizado» oculta si habló el servidor del token o la política del recurso. En un incidente, esa ambigüedad se transforma en una disputa de responsabilidades.

La identidad de quien consulta forma parte de la respuesta

La RFC 7662 permite que el servidor de autorización adapte la información al recurso protegido que realiza la consulta. No tiene por qué entregar el mismo expediente a todos. Incluso puede limitar los alcances devueltos a los que resultan pertinentes para ese destinatario. La medida reduce exposición y reconoce que la utilidad del token tiene contexto.

Por eso, copiar el resultado visto por un servicio no prueba lo que otro servicio habría recibido. Una evidencia completa conserva quién preguntó, cuándo, qué audiencia estaba en juego y qué atributos llegaron. Dos respuestas diferentes pueden ser intencionadas y correctas, no síntomas de una réplica rota.

La RFC 8707 añade otra distinción útil. Un indicador de recurso permite expresar dónde se pretende utilizar el token; el alcance indica qué clase de acceso se solicita. El destino no es el permiso, y el permiso abstracto tampoco es el resultado de una orden concreta.

Los campos opcionales requieren la misma disciplina. exp y nbf delimitan el tiempo; aud e iss ayudan a situar audiencia y emisor; sub, username y client_id pueden referirse a actores distintos. jti identifica el token. Como un token suele acompañar muchas solicitudes, ese identificador no puede sustituir al número de pedido, a la clave de una transferencia o al ID de una ejecución.

Un caché convierte el presente en una fotografía

Consultar en cada llamada puede concentrar carga en el servidor de autorización y añadir una dependencia de red. La RFC 7662 permite almacenar temporalmente las respuestas de introspección. También señala el intercambio: el caché mejora el rendimiento, pero reduce la vivacidad del dato.

Un recurso puede recibir el resultado activo a las 10:00 y conservarlo durante cinco minutos. A las 10:01, el titular revoca el token mediante el mecanismo de la RFC 7009, o un administrador invalida la concesión. El recurso podría seguir aceptando el dato anterior hasta las 10:05. El servidor de autorización posee una verdad nueva; el recurso decide con una fotografía antigua que su configuración le autorizó a guardar.

El TTL es, por tanto, una elección de seguridad y no solo de rendimiento. Debe responder a la duración del token, la rapidez prometida de la revocación, la sensibilidad de la operación, la disponibilidad del endpoint y el daño posible durante la ventana. Leer un catálogo y cambiar un factor de recuperación no merecen automáticamente el mismo margen de antigüedad.

Revocar tampoco deshace efectos. La RFC 7009 invalida el token y puede afectar a elementos relacionados según el servidor, pero no recupera un secreto ya mostrado ni revierte una transferencia ya liquidada. Detener usos futuros y reparar consecuencias pasadas son responsabilidades diferentes.

La aplicación todavía debe explicar qué ocurrió

Después de validar y autorizar, una operación aún puede quedar en tierra de nadie. El servicio falla antes de confirmar el cambio, o lo confirma y pierde la respuesta. Una cola acepta la tarea y un consumidor la rechaza más tarde. El cliente reintenta con el mismo token todavía activo. Dos solicitudes legítimas pueden representar una sola intención y producir dos efectos.

La introspección no contiene un recibo de aplicación. jti correlaciona usos de un token, no identifica cada intento. El alcance clasifica permisos, no comandos. El registro de la consulta prueba que se devolvieron atributos, no que una transacción de negocio llegó a su postcondición.

Las API con efectos importantes necesitan una identidad duradera para la operación: una clave de idempotencia, un identificador de comando, una precondición de versión u otro mecanismo del dominio. También necesitan una forma de consultar el desenlace tras un timeout. Validación, decisión local, identidad de la operación, commit y entrega de respuesta son hechos enlazables, pero no equivalentes.

La lectura exigente de la RFC 7662 es también la más generosa. Su respuesta resuelve una pregunta estrecha que los sistemas distribuidos no pueden improvisar sin riesgo. Mantenerla dentro de ese alcance evita que una buena señal de credenciales se convierta en una mala explicación de la aplicación.

Fuentes