Saltar al contenido principal
Aquí tienes algunas consideraciones básicas que debes tener en cuenta al usar tokens:
  • Mantenlo en secreto. Mantenlo a salvo: La clave de firma debe tratarse como cualquier otra credencial y revelarse solo a los servicios que la necesiten.
  • No agregues datos sensibles al payload: Los tokens se firman para protegerlos contra manipulaciones y se pueden decodificar fácilmente. Agrega al payload la cantidad mínima indispensable de claims para obtener el mejor rendimiento y seguridad.
  • Asigna una expiración a los tokens: Técnicamente, una vez que un token está firmado, es válido para siempre, a menos que se cambie la clave de firma o se establezca explícitamente una expiración. Esto podría generar problemas, así que ten una estrategia para hacer que los tokens expiren y/o revocarlos.
  • Usa HTTPS: No envíes tokens a través de conexiones que no usen HTTPS, ya que esas solicitudes pueden ser interceptadas y los tokens verse comprometidos.
  • Considera todos tus casos de uso de autorización: Puede ser necesario agregar un sistema secundario de verificación de tokens que garantice que los tokens fueron generados por tu servidor para cumplir con tus requisitos.
  • Almacena y reutiliza: Reduce los viajes de ida y vuelta innecesarios que amplían la superficie de ataque de tu aplicación y optimiza los límites de tokens de tu plan (cuando corresponda) almacenando obtenidos del . En lugar de solicitar un token nuevo, usa el token almacenado en futuras llamadas hasta que expire. La forma en que almacenes los tokens dependerá de las características de tu aplicación: las soluciones típicas incluyen bases de datos (para aplicaciones que necesitan realizar llamadas a la API independientemente de si hay una sesión activa) y sesiones HTTP (para aplicaciones cuya ventana de actividad se limita a una sesión interactiva). Para ver un ejemplo de almacenamiento del lado del servidor y reutilización de tokens, consulta Almacenamiento de tokens.

​
Tokens frente a cookies

Por lo general, las aplicaciones de una sola página (como React, Vue y AngularJS + Node), las aplicaciones móviles nativas (como iOS y Android) y las API web (escritas en Node, Ruby, ASP.NET o una combinación de ellos) son las que más se benefician de la autenticación basada en tokens. Las aplicaciones web tradicionales del lado del servidor han utilizado tradicionalmente la autenticación basada en cookies. La autenticación basada en tokens se implementa generando un token cuando el usuario se autentica y, después, enviando ese token en el encabezado Authorization de cada solicitud posterior a tu API. Lo ideal es que ese token sea un estándar, como , ya que encontrarás bibliotecas en la mayoría de las plataformas y no querrás implementar tu propia criptografía. Con ambos enfoques, puedes obtener la misma cantidad de información del usuario. Esto se controla mediante el parámetro scope enviado en la solicitud de inicio de sesión (ya sea usando Lock, nuestra biblioteca de JavaScript, o un enlace simple). scope es un parámetro del método .signin({scope: 'openid name email'}) que termina formando parte de la cadena de consulta en la solicitud de inicio de sesión. De forma predeterminada, usamos scope=openid en la autenticación basada en tokens para evitar que el token sea demasiado grande. Puedes controlar qué reclamaciones estándar de Connect (OIDC) quieres obtener en el token añadiéndolas como valores de scope. Por ejemplo, scope=openid name email family_name address phone_number. Para obtener más información, consulta Standard Claims on openid.net. Puedes combinar la autenticación basada en tokens con la autenticación basada en cookies. Ten en cuenta que las cookies funcionarán perfectamente si la aplicación web y la API se sirven desde el mismo dominio, por lo que quizá no necesites autenticación basada en tokens. Si la necesitas, también devolvemos un JWT en el flujo de la aplicación web. Cada uno de nuestros SDK lo hace de forma diferente. Si quieres llamar a tus API desde JavaScript (en lugar de usar la cookie existente), entonces tienes que configurar los tokens de acceso usando Web Workers o cierres de JavaScript para gestionar la transmisión y el almacenamiento de tokens. Para obtener más información, lee la sección Browser in-memory scenarios de nuestra página de Almacenamiento de tokens.

​
Uso del token de actualización

Solo puedes obtener un si implementas los siguientes flujos: Si restringes el acceso sin conexión a tu API mediante la protección configurada con el interruptor Allow Offline Access en Auth0 Dashboard > Applications > APIs > Settings, Auth0 no devolverá un token de actualización para la API (aunque incluyas el scope offline_access en tu solicitud). Las Rules se ejecutan durante el intercambio del token de actualización. Para aplicar lógica especial, puedes revisar la propiedad context.protocol en tu rule. Si el valor es oauth2-refresh-token, significa que la rule se está ejecutando durante el intercambio. Al intentar obtener un token de actualización, el parámetro no está disponible en el objeto de contexto de Rules. Si recibes un error al intentar agregar el parámetro audience, verifica que no esté configurado en el token. Si intentas redirigir con context.redirect, el flujo de autenticación devolverá un error. Si has agregado custom claims a tus tokens mediante una rule, esas custom claims aparecerán en los nuevos tokens emitidos al usar un token de actualización mientras la rule siga activa. Aunque los nuevos tokens no heredan automáticamente las custom claims, las rules se ejecutan durante el flujo de token de actualización, por lo que se ejecutará el mismo código. Esto te permite agregar o cambiar custom claims en tokens recién emitidos sin obligar a las aplicaciones autorizadas previamente a obtener un nuevo token de actualización.

​
Límites de los tokens de actualización

Auth0 limita la cantidad de tokens de actualización activos a 200 por usuario y por aplicación. Este límite solo se aplica a los tokens activos. Si se alcanza el límite y se crea un nuevo token de actualización, el sistema revoca y elimina el token más antiguo de ese usuario y esa aplicación. Los tokens revocados y expirados no cuentan para este límite.

​
Pruebas automatizadas

Los tokens de actualización se acumulan debido a las pruebas automatizadas y, por lo general, se usan durante toda la duración de la prueba. Para evitar una acumulación de tokens sujeta a los límites de tokens de actualización, puede usar la de Auth0 para eliminar los tokens de actualización innecesarios.
  1. Cree un usuario con Management API. Usará este usuario para las pruebas.
  2. La respuesta devuelve un user_id que debe conservar durante las pruebas para usarlo más adelante.
  3. Una vez finalizadas las pruebas, elimine el usuario mediante Management API. Cuando se elimina el usuario de prueba, también se eliminan los elementos asociados, incluidos los tokens de actualización.
Para este caso de uso, no recomendamos usar un ID de usuario estático. Tampoco recomendamos conservar los usuarios y elementos de prueba ni limpiar los tokens de actualización mediante los endpoints de credenciales de dispositivo, ya que podría alcanzar los límites de tasa de Management API. Para obtener más información, consulte Límites de tasa de los endpoints de Management API.
Si desea conservar el usuario de prueba para pruebas futuras:
  1. Liste los tokens de actualización del usuario mediante el endpoint de credenciales de dispositivo de Management API. El endpoint devolverá un máximo de 1000 tokens sin un orden específico, independientemente de la cantidad de tokens acumulados o del uso de paginación.
  2. Elimine esas credenciales con el método DELETE.
  3. Si el usuario tiene más de 1k tokens, repita el proceso de listar y eliminar tokens hasta que no queden más tokens para el usuario.

​
Configurar tokens de actualización con caducidad

Cuando los usuarios inician sesión en su aplicación con Auth0 y se solicita offline_access en la solicitud de autorización, se les emite un nuevo token de actualización. Si los usuarios cierran sesión y vuelven a iniciarla en el mismo dispositivo, se emite un nuevo token de actualización. Según cómo su aplicación almacene y utilice los tokens de actualización, el token de actualización anterior del primer inicio de sesión podría quedar obsoleto, y lo más probable es que su aplicación utilice los nuevos tokens de actualización si ambos se emiten con la misma audiencia. Para obtener más información, consulte Almacenamiento de tokens. Para evitar acumular tokens de actualización obsoletos, aunque el límite de tokens de actualización elimina primero el token más antiguo, le recomendamos configurar la caducidad de los tokens de actualización. Tanto los tokens de actualización rotativos como los no rotativos (o reutilizables) pueden configurarse para caducar con valores de expiración por inactividad o absoluta. Ambos valores de expiración ayudan a eliminar los tokens que no están en uso activo y a evitar que se acumulen tokens para el usuario. Para obtener más información, consulte Configure Refresh Token Expiration.

​
Validación de JWT

Recomendamos encarecidamente usar middleware o alguna de las bibliotecas de terceros de código abierto disponibles para analizar y validar JWT. En JWT.io encontrará bibliotecas para varias plataformas y lenguajes, como .NET, Python, Java, Ruby, Objective-C, Swift y PHP.

​
Algoritmos de firma

El algoritmo utilizado para firmar los tokens emitidos para tu aplicación o API. Una firma forma parte de un JWT y se utiliza para verificar que el emisor del token es quien dice ser y para garantizar que el mensaje no haya sido modificado en el camino. Para obtener más información sobre los JWT, lee JSON Web Tokens. Para obtener más información sobre las firmas, lee JSON Web Token Structure. Puedes seleccionar entre los siguientes :
  • RS256 (RSA Signature with SHA-256): Un algoritmo asimétrico, lo que significa que hay dos claves: una clave pública y una clave privada que debe mantenerse en secreto. Auth0 tiene la clave privada utilizada para generar la firma, y el consumidor del JWT obtiene una clave pública desde los endpoints de metadatos proporcionados por Auth0 y la utiliza para validar la firma del JWT.
  • HS256 (HMAC with SHA-256): Un algoritmo simétrico, lo que significa que solo hay una clave privada que debe mantenerse en secreto y que se comparte entre ambas partes. Dado que la misma clave se utiliza tanto para generar la firma como para validarla, se debe tener cuidado para asegurarse de que la clave no se vea comprometida. Esta clave privada (o secreto) se crea cuando registras tu Application () o API (Signing Secret) y eliges el algoritmo de firma HS256.
La práctica más segura, y nuestra recomendación, es usar RS256 porque:
  • Con RS256, tienes la certeza de que solo quien posee la clave privada (Auth0) puede firmar tokens, mientras que cualquiera puede comprobar si el token es válido usando la clave pública.
  • Con RS256, puedes solicitar un token válido para múltiples audiencias.
  • Con RS256, si la clave privada se ve comprometida, puedes implementar la rotación de claves sin tener que volver a desplegar tu aplicación o API con el nuevo secreto (lo cual tendrías que hacer si usaras HS256).
  • Con HS256, si la clave secreta se ve comprometida, tendrías que volver a desplegar la API con el nuevo secreto.

​
Claves de firma

Es una buena práctica asumir que puede haber varias claves de firma en tu JWKS. Esto puede parecer innecesario, ya que el endpoint JWKS de Auth0 normalmente contiene una sola clave de firma; sin embargo, es posible encontrar varias claves en el JWKS al rotar los certificados de firma. Te recomendamos almacenar en caché tus claves de firma para mejorar el rendimiento de la aplicación y evitar alcanzar los límites de velocidad, pero debes asegurarte de que, si falla la decodificación de un token, invalides la caché y recuperes nuevas claves de firma antes de volver a intentarlo solo una vez más.

​
Más información