Inspección de tokens OAuth 2.0

La inspección de tokens OAuth 2.0 define un método que permite a un recurso protegido autorizado consultar al servidor de autorización para determinar los metadatos asociados con un token dado (ya sea un token de acceso o un token de actualización), proporcionado por un cliente OAuth. Basado en los metadatos del token específico, permite al propietario del recurso acceder al recurso protegido.

Estos metadatos incluyen:

• Si el token está activo actualmente (o si ha expirado o sido revocado)
• Los permisos que el token de acceso otorga (típicamente transmitidos a través de los alcances de OAuth 2.0)
• El contexto de autorización en el que se concedió el token (incluyendo quién autorizó el token y a qué cliente fue emitido)

La introspección de tokens permite al recurso protegido consultar esta información, independientemente de si está contenida dentro del mismo token.

Hay dos tipos de tokens de acceso, dependiendo de cómo están codificados:

• Basado en identificador: El token representa un identificador aleatorio, difícil de adivinar, asociado con la autorización en la base de datos del servidor de autorización.
• Autocontenido: La autorización está codificada dentro del mismo token y está protegida a través de criptografía para evitar manipulaciones. JSON Web Token (JWT) es el estándar común para este método.

Para tokens autocontenidos, los metadatos relacionados con la autorización pueden ser directamente analizados desde el token de acceso. Sin embargo, para los tokens basados en identificador, se debe utilizar la funcionalidad de introspección de tokens del servidor de autorización para validar/recuperar los metadatos.

Solicitud de introspección de tokens#

Usar tokens de acceso basados en identificador requiere verificación con el servidor de autorización a través de una solicitud de red. Hay un protocolo estándar para esto llamado Introspección de Tokens OAuth 2.0 (RFC 7662).

El recurso protegido enviará el token por POST al endpoint de introspección del servidor de autorización, y a cambio, recibirá un objeto JSON que contiene los parámetros del token.

Ten en cuenta que las solicitudes de introspección no pueden ser iniciadas arbitrariamente; deben cumplir una de las siguientes condiciones:

• Autenticación usando credenciales (que deben estar pre-registradas con el servidor de autorización), o
• Autorización usando un token de acceso.

Como resultado, en esta interacción específica, el recurso protegido se convierte en el cliente OAuth, y el servidor de autorización se convierte en el recurso protegido.

A continuación se muestra un ejemplo de una solicitud de introspección, donde el recurso protegido se autentica usando un ID de cliente y un secreto de cliente, que se obtuvieron después de registrarse como cliente OAuth con el servidor de autorización.

A continuación se muestra un ejemplo de una solicitud de introspección que utiliza directamente un token de acceso. El token de acceso se puede obtener directamente del endpoint /token usando las credenciales de una aplicación de máquina a máquina registrada y el tipo de concesión client_credentials.

Respuesta de introspección de tokens#

El parámetro más importante es active, que es un valor booleano. Si es true, indica que el token es válido, y el objeto JSON incluirá otros detalles del token, como los valores del alcance. Si es false, el token es inválido o ha expirado, y el recurso protegido debe devolver una respuesta 401 Unauthorized con el código de error invalid_token.

Aquí hay un ejemplo de respuesta para un token válido:

Aparte de active, que es obligatorio, todos los demás parámetros son opcionales.

El recurso protegido puede usar estos campos adicionales para determinar los permisos de acceso, de manera similar a como analizaría y validaría un token de acceso JWT.