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.
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.
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.
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:
aud del token.aud y otros claims relacionados con permisos para asegurar la solicitud de API.🤔 Pero ¿qué pasa si el cliente no especifica el recurso al solicitar el token de acceso?
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.
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.