Conectando los puntos: Una exploración en profundidad de OIDC resource y sus tokens de acceso JWT

Antecedentes#

En una sesión anterior, proporcionamos una introducción al Protocolo OpenID Connect (OIDC), los tokens de actualización, los tokens de acceso y los tokens de ID, componentes esenciales para construir una autenticación robusta en su aplicación. Sin embargo, aún quedan preguntas en nuestra comunidad, con una consulta recurrente: "¿Por qué mi token de acceso no es un JWT?"

Para aquellos nuevos en los conceptos, o incluso para aquellos que necesitan un repaso, esta entrada de blog tiene como objetivo arrojar luz sobre la relación entre los indicadores de recursos OIDC y su papel en la obtención de tokens de acceso.

Entendiendiendo OIDC resource#

Si está familiarizado con el protocolo OAuth 2.0, el término “recurso” debería sonarle. Como OIDC se basa en OAuth 2.0, hereda este mismo concepto.

Un "recurso" o "recurso protegido" es una representación de una entidad a la que la aplicación cliente desea acceder en nombre del usuario autenticado. Esto podría ser información del usuario, APIs del servidor, o cualquier otro dato autorizado por su servidor.

Según el protocolo, el recurso es un parámetro en las solicitudes al servidor de autorización. Es un valor representado como un URI absoluto, como https://mi-empresa.com/api. Actúa como un identificador para el recurso, correspondiendo potencialmente a una ubicación accesible por la red o incluso a un URI único pero ficticio.

En Logto, puedes crear un “recurso API” a través de la página “Consola de Administración → Recursos API”. Puedes referirte a esta documentación para obtener más detalles.

Token de acceso JWT#

El token de acceso formato JWT (JSON web token) se emite sólo cuando el parámetro "recurso" se especifica durante la solicitud del token de acceso, y lleva un conjunto de claims, que puedes descifrar y validar, por ejemplo, para asegurar la integridad del token y los permisos del usuario.

Este "recurso" entonces se convierte en uno de los aud claim del token en el JWT, indicando la audiencia prevista para el token. Ver RFC-7519.

Entonces, la relación se vuelve clara:

• Especifica el indicador de recurso al solicitar un token JWT.
• El indicador de recurso se alinea con el claim aud del token.
• Al hacer solicitudes de API, el token de acceso JWT debe incluirse como el encabezado del token de bearer. Tu servidor de API debe descifrar y validar el claim aud y otros claims relacionados con permisos para asegurar la solicitud de API.
• Cada token de acceso corresponde a un único recurso. Si tienes múltiples recursos API registrados con diferentes URIs, solicita tokens de acceso distintos para cada uno.

🤔 Pero ¿qué pasa si el cliente no especifica el recurso al solicitar el token de acceso?

Token de acceso opaco#

En el caso de Logto, si el indicador de recurso no se especifica al solicitar el token de acceso, el servidor de autorización supone que es para el endpoint OIDC /userinfo, y así se emitirá un token de acceso opaco que puede ser utilizado más tarde por el cliente para solicitar el perfil de usuario como el ID de usuario, nombre, correo electrónico, etc., desde el endpoint userinfo de OIDC.

En cualquier SDK de Logto, puedes obtener tal token si llamas a getAccessToken() o solicitas directamente el endpoint de token OIDC sin especificar el parámetro resource.

Toma en cuenta que este token de acceso opaco no es adecuado para tus propias solicitudes de recursos API, ya que no hay forma de verificarlo sin solicitar al servidor OIDC.

En resumen#

Los recursos OIDC definen datos específicos o servicios a los que una aplicación cliente quiere acceder en nombre del usuario, con los tokens de acceso JWT sirviendo como los medios seguros para este acceso. El claim "aud" en los tokens de acceso JWT se alinea con el indicador de recurso, ayudando a los servidores a verificar los permisos al momento de las solicitudes de los clientes.

En Logto, el token de acceso opaco es únicamente para obtener la información del perfil del usuario desde el endpoint userinfo de OIDC, mientras que los clientes pueden solicitar múltiples tokens de acceso, cada uno dedicado a un recurso específico.

Esperamos que esta entrada de blog aclare cualquier duda y conecte los puntos para ti. No dudes en hacernos saber tus pensamientos.