Añade reclamos personalizados para tokens de acceso JWT con Logto para mejorar tu autorización

En artículos anteriores, mencionamos que cada vez más sistemas están utilizando tokens de acceso en formato JWT para la autenticación de usuarios y el control de acceso. Una de las razones importantes para esto es que el JWT puede contener información útil, como roles de usuario y permisos. Esta información puede ayudarnos a transmitir la información de identidad del usuario entre el servidor y el cliente, logrando así la autenticación de usuarios y el control de acceso.

Por lo general, la información contenida en el JWT es determinada por el servidor de autenticación. Según el protocolo OAuth 2.0, el JWT generalmente contiene campos como sub (asunto), aud (audiencia) y exp (tiempo de expiración), los cuales se denominan comúnmente reclamos. Estos reclamos pueden ayudar a verificar la validez del token de acceso.

Sin embargo, existen innumerables escenarios en los que se utiliza el JWT para la verificación, y los reclamos comunes de JWT a menudo no pueden satisfacer las necesidades del usuario. A menudo la gente se pregunta si ya que el JWT puede contener alguna información, ¿podemos agregarle información adicional para facilitar la autorización?

La respuesta es SÍ, podemos agregar reclamos personalizados al JWT, como el alcance actual del usuario y el nivel de suscripción. De esta manera, podemos transmitir la información de identidad del usuario entre el cliente y el servidor (aquí nos referimos al servidor que proporciona varios servicios diferentes, también llamado proveedor de servicios), para lograr la autenticación de usuarios y el control de acceso.

Para obtener información sobre los reclamos estándar del JWT, consulte RFC7519. Logto, como una solución de identidad que admite tanto la autenticación como la autorización, ha extendido los reclamos de recursos y alcance sobre esta base para admitir el estándar RBAC. Aunque la implementación de RBAC de Logto es estándar, no es lo suficientemente simple y flexible como para adaptarse a todos los casos de uso.

Basado en esto, Logto lanzó una nueva función para personalizar reclamos JWT, lo que permite a los usuarios personalizar reclamos JWT adicionales, de modo que la autenticación y el control de acceso de los usuarios se puedan implementar de manera más flexible.

¿Cómo funcionan los reclamos personalizados de JWT en Logto?#

Puedes acceder a la página de listado de JWT personalizados haciendo clic en el botón "JWT claims" en la barra lateral.

Comencemos añadiendo reclamos personalizados para los usuarios finales.

En el editor de la izquierda, puedes personalizar tu función getCustomJwtClaims. Este método tiene tres parámetros de entrada: token, data y envVariables.

• token es la carga útil del token de acceso en bruto obtenida según las credenciales del usuario final actual y la configuración de tu sistema, y la información relacionada con el acceso del usuario en Logto.
• data es toda la información sobre el usuario en Logto, incluidos todos los roles del usuario, identidades de acceso social, identidades SSO, membresías de la organización, etc.
• envVariables son las variables de entorno que configuraste en Logto para el escenario de uso del token de acceso del usuario final actual, como clave(s) API de las API externas necesarias, etc.

Las tarjetas a la derecha se pueden expandir para mostrar la introducción de los parámetros correspondientes, y también puedes configurar las variables de entorno para el escenario actual aquí.

Después de leer las introducciones de todas las tarjetas a la derecha, puedes cambiar al modo de prueba, donde puedes editar los datos de prueba y utilizar los datos de prueba editados para verificar si el comportamiento del script que escribiste en el editor de código a la izquierda cumple con tus expectativas.

Este es un diagrama de secuencia que muestra el proceso de ejecución de la función getCustomJwtClaims cuando un usuario final inicia una solicitud de autenticación a Logto y finalmente obtiene el token de acceso en formato JWT devuelto por Logto.

Si la función JWT personalizado no está habilitada, el paso 3 en la figura se omitirá y el paso 4 se ejecutará justo después de que finalice el paso 2. En este caso, Logto asumirá que el valor de retorno de getCustomJwtClaims es un objeto vacío, y luego continuará con los pasos subsiguientes.

Mejora tu autorización con reclamos personalizados de JWT: un ejemplo práctico#

En la sección anterior, presentamos el principio de funcionamiento del JWT personalizado de Logto. En esta parte, te mostraremos cómo utilizar los reclamos personalizados de JWT de Logto para mejorar la flexibilidad de la autorización y el rendimiento del proveedor de servicios a través de un ejemplo del mundo real.

Configuración del escenario#

El equipo de John desarrolló una aplicación de Asistente de IA que permite a los usuarios conversar con robots de IA para obtener varios servicios.

Los servicios del robot de IA se dividen en servicios gratuitos y servicios de pago. Los servicios gratuitos incluyen recomendaciones especiales de tarifas aéreas, mientras que los servicios de pago incluyen predicciones del mercado de valores.

La aplicación del Asistente de IA utiliza Logto para gestionar a todos los usuarios, que se dividen en tres tipos: usuarios gratuitos, usuarios prepagados y usuarios premium. Los usuarios gratuitos solo pueden utilizar servicios gratuitos, los usuarios prepagados pueden utilizar todos los servicios (pagados según uso), y los usuarios premium pueden utilizar todos los servicios (pero tienen límites de uso para evitar el uso malintencionado).

Además, la aplicación del Asistente de IA utiliza Stripe para gestionar los pagos de usuarios y tiene su propio servicio de registro para registrar los registros de operaciones de usuarios.

Configuraciones de Logto#

Primero creamos recursos de API para el servicio de la aplicación del Asistente de IA y creamos dos ámbitos, recommend:flight y predict:stock.

Luego creamos dos roles, free-user y paid-user, y asignamos los ámbitos correspondientes:

• Asignar el ámbito recommend:flight al rol free-user.
• Asignar ambos ámbitos recommend:flight y predict:stock al rol paid-user.

Finalmente, creamos tres usuarios, free-user, prepaid-user y premium-user, y asignamos los roles correspondientes:

• Asignar el rol free-user al usuario free-user.
• Asignar el rol paid-user a los usuarios prepaid-user y premium-user.

Como se muestra en la siguiente figura, para implementar la información de autorización requerida para el escenario descrito anteriormente, esperamos incluir la información de roles, balance y numOfCallsToday del usuario actualmente registrado en el JWT. Al verificar el token de acceso en la aplicación del Asistente de IA, esta información se puede utilizar para realizar una verificación de permisos rápidamente.

Después de configurar los envVariables, implementamos la función getCustomJwtClaims y hacemos clic en el botón "Run test" para ver el resultado de los reclamos JWT adicionales basados en los datos de prueba actuales.

Dado que no hemos configurado los datos de prueba para data.user.roles , los roles que se muestran en el resultado es un array vacío.

Verifica si la función JWT personalizada se activa#

Según la configuración de Logto anterior, obtuvimos los resultados correspondientes en la prueba. A continuación, utilizaremos la aplicación de ejemplo proporcionada por Logto para verificar si nuestro JWT personalizado es efectivo. Encuentra el SDK con el que estés familiarizado en Logto SDKs y despliega una aplicación de ejemplo según la documentación y el repositorio de GitHub correspondiente.

Basado en la configuración que describimos anteriormente, tomando el React SDK como ejemplo, necesitamos actualizar la configuración correspondiente en LogtoConfig:

Después de iniciar sesión como usuario free_user en la aplicación de ejemplo que simula la aplicación del Asistente de IA, podemos ver la información roles, balance, numOfCallsToday, isPaidUser e isPremiumUser que añadimos al ver la parte de carga útil del token de acceso JWT.

Los valores de balance, numOfCallsToday, isPaidUser e isPremiumUser son consistentes con la prueba anterior, y roles es igual a ["free-user"]. Esto se debe a que en el proceso de inicio de sesión real del usuario final, obtendremos todos los datos accesibles del usuario y los procesaremos en consecuencia.

Para los usuarios premium, podemos ver que roles es ["paid-user"] y tanto isPaidUser como isPremiumUser son true.

Actualiza la lógica de autorización del proveedor de servicios#

En los pasos anteriores, añadimos reclamos personalizados basados en las necesidades comerciales al token de acceso del usuario. A continuación, podemos utilizar estos reclamos para realizar rápidamente la verificación de autorización.

Aquí te proporcionamos la lógica de Logto para verificar tokens de acceso JWT en el lado API. La implementación completa del código se puede encontrar en el repositorio de GitHub:

Puedes referirte a la lógica de la API de Logto para verificar tokens de acceso y personalizarla según tu propia lógica de negocio. Por ejemplo, para el escenario de la aplicación del Asistente de IA descrito aquí, puedes añadir una lógica de verificación para reclamos personalizados como roles, balance, numOfCallsToday, isPaidUser e isPremiumUser en la función verifyBearerTokenFromRequest.

El ejemplo anterior es para el escenario donde afecta el inicio de sesión del usuario final y la obtención del token de acceso JWT. Si tu caso de uso es máquina-a-máquina (M2M), también puedes configurar reclamos personalizados de JWT para aplicaciones M2M por separado.

Configurar JWT personalizados para usuarios no afectará el resultado de las aplicaciones M2M al obtener tokens de acceso, y viceversa.

Debido a la generalidad de las conexiones M2M, Logto no proporciona actualmente la función del método getCustomJwtClaims de las aplicaciones M2M para aceptar datos internos de Logto. En otros aspectos, el método de configuración de JWT personalizados para aplicaciones M2M es el mismo que el de las aplicaciones de usuarios. Este artículo no lo profundizará. Puedes usar la función JWT personalizada de Logto para comenzar.

¿Por qué usar reclamos personalizados de JWT?#

Hemos proporcionado el escenario de la aplicación del Asistente de IA para John y cómo utilizar la función de JWT personalizado de Logto para lograr una verificación de autorización más flexible. En este proceso, podemos ver las ventajas de la función de JWT personalizado:

1. Sin la función de JWT personalizado, los usuarios necesitarían solicitar una API externa (como lo que haces en getCustomJwtClaims) cada vez que verifiquen permisos. Para el proveedor de servicios que proporciona esta API, esto podría aumentar la carga adicional. Con la función de JWT personalizado, esta información puede incluirse directamente en el JWT, reduciendo las llamadas frecuentes a la API externa.
2. Para los proveedores de servicios, la función de JWT personalizado puede ayudarles a verificar los permisos de los usuarios más rápidamente, especialmente cuando el cliente llama frecuentemente al proveedor de servicios, mejorando el rendimiento del servicio.
3. La función de JWT personalizado puede ayudarte a implementar rápidamente información de autorización adicional requerida por el negocio, y la información puede transmitirse entre el cliente y el proveedor de servicios de manera segura, ya que el JWT es autónomo y podría ser encriptado para que sea difícil de falsificar.

Al mismo tiempo, dado que getCustomJwtClaims se ejecuta cada vez que un usuario necesita que Logto emita un token de acceso, es necesario evitar ejecutar lógica excesivamente compleja y solicitudes de API externas con altos requisitos de ancho de banda. De lo contrario, podría llevar demasiado tiempo que los usuarios finales esperen el resultado de getCustomJwtClaims durante el proceso de inicio de sesión. Si tu getCustomJwtClaims devuelve un objeto vacío, te recomendamos encarecidamente que elimines temporalmente este elemento de configuración hasta que realmente necesites usarlo.

Conclusión#

En este artículo, Logto ha extendido el token de acceso JWT básico y ha ampliado la función de reclamos adicionales de JWT para permitir que los usuarios pongan información adicional de usuario final en el token de acceso JWT según sus necesidades comerciales, de modo que una vez que el usuario haya iniciado sesión, se puedan verificar rápidamente los permisos del usuario.

Proporcionamos el escenario de la aplicación del Asistente de IA de John y demostramos cómo utilizar la función de JWT personalizado de Logto para lograr una verificación de autorización más flexible. También señalamos algunos puntos clave al utilizar JWT personalizados. En combinación con escenarios comerciales reales, los usuarios pueden poner diversas informaciones relacionadas con el usuario en el token de acceso JWT según sus necesidades comerciales, de modo que el proveedor de servicios pueda verificar rápidamente los permisos del usuario.