Redirigir a los usuarios desde Rules

Aprenda a personalizar los flujos de autenticación redirigiendo a los usuarios mediante Rules. Algunos ejemplos de áreas que se pueden personalizar incluyen MFA, la aceptación de la política de privacidad y la recopilación de datos de usuario.

La fecha de fin de vida útil (EOL) de Rules y Hooks será el 18 de noviembre de 2026, y ya no están disponibles para los nuevos inquilinos creados a partir del 16 de octubre de 2023. Los inquilinos existentes con Hooks activos conservarán el acceso al producto Hooks hasta el fin de su vida útil.

Recomendamos encarecidamente que uses Actions para extender Auth0. Con Actions, tienes acceso a información de tipos más completa, documentación en línea y paquetes públicos de npm, y puedes conectar integraciones externas que mejoran tu experiencia general de extensibilidad. Para obtener más información sobre lo que ofrece Actions, lee Cómo funcionan las Actions de Auth0.

Para ayudarte con la migración, ofrecemos guías que te ayudarán a migrar de Rules a Actions y migrar de Hooks a Actions. También contamos con una página específica, Move to Actions, que destaca comparaciones de funcionalidades, una demostración de Actions y otros recursos para ayudarte en tu proceso de migración.

Para obtener más información sobre la retirada de Rules y Hooks, consulta nuestra entrada del blog: Preparing for Rules and Hooks End of Life.

Puedes usar Auth0 Rules para redirigir a los usuarios antes de que se complete una transacción de autenticación. Esto te permite implementar flujos de autenticación personalizados que requieren interacción adicional del usuario más allá del formulario de inicio de sesión estándar. Las Rules de redirección se usan habitualmente para implementar Autenticación multifactor (MFA) personalizada en Auth0, pero también se pueden usar para:

• Aceptación personalizada de políticas de privacidad, términos del servicio y formularios de divulgación de datos.
• Recopilar de forma segura, una sola vez, datos de perfil adicionales obligatorios.
• Permitir que los usuarios remotos de Active Directory cambien su contraseña.
• Exigir que los usuarios proporcionen una verificación adicional al iniciar sesión desde ubicaciones desconocidas.
• Recopilar más información sobre tus usuarios de la que proporcionaron durante el registro inicial.

Puedes redirigir a un usuario una vez por flujo de autenticación. Si tienes una Rule que redirige a un usuario, no puedes invocar una segunda Rule para redirigirlo más adelante.

Para obtener más información, consulta Autenticación multifactor en Auth0.

​

Iniciar la redirección y reanudar la autenticación

Establezca la propiedad context.redirect de la siguiente manera:

function (user, context, callback) {
  context.redirect = {
    url: "https://example.com/foo"
  };
  return callback(null, user, context);
}

Una vez que se hayan ejecutado todas las Rules, Auth0 redirige al usuario a la URL especificada en la propiedad context.redirect.url. Auth0 también incluye un parámetro state en esa URL. Por ejemplo:

https://example.com/foo?state=abc123

La URL de redirección debe extraer el parámetro state y devolverlo a Auth0 para reanudar la transacción de autenticación. El estado es un valor opaco que se utiliza para evitar ataques de Cross-Site Request Forgery (CSRF).

Después de la redirección, reanude la autenticación redirigiendo al usuario al endpoint /continue e incluyendo el parámetro state que recibió en la URL. Si no envía el estado original de vuelta al endpoint /continue, Auth0 perderá el contexto de la transacción de inicio de sesión y el usuario no podrá iniciar sesión debido a un error invalid_request.

Por ejemplo:

Si usas un dominio personalizado:

https://{yourAuth0CustomDomain}/continue?state={originalState}

THE_ORIGINAL_STATE es el valor que Auth0 generó y envió a la URL de redirección. Por ejemplo, si tu Rule redirigía a https://example.com/foo, Auth0 usaría una URL de redirección similar a https://example.com/foo?state=abc123. Por lo tanto, abc123 sería el valor de THE_ORIGINAL_STATE. Para reanudar la transacción de autenticación, redirige a:

Cuando se haya redirigido a un usuario al endpoint /continue:

• todas las Rules se ejecutarán de nuevo; sin embargo, context.redirect se ignorará para permitir que la autenticación continúe.
• cualquier cambio en el objeto de usuario se realiza durante la redirección, antes de llamar al endpoint /continue. Por ejemplo, las actualizaciones realizadas mediante la Management API de Auth0 estarán disponibles después de continuar la transacción.

​

Validar la reanudación del inicio de sesión

Para distinguir entre los inicios de sesión iniciados por el usuario y los flanudados, compruebe la propiedad context.protocol:

function (user, context, callback) {
    if (context.protocol === "redirect-callback") {
        // El usuario fue redirigido al endpoint /continue
    } else {
        // El usuario está iniciando sesión directamente
    }
}

​

Ejemplo para forzar el cambio de contraseña

En algunos casos, es posible que desee obligar a los usuarios a cambiar su contraseña en determinadas condiciones. Puede escribir una Rule con el siguiente comportamiento:

1. El usuario intenta iniciar sesión y necesita cambiar su contraseña.
2. Se redirige al usuario a una página específica de la aplicación con un JWT en la cadena de consulta. Este JWT garantiza que solo se pueda cambiar la contraseña de este usuario y debe ser validado por la aplicación.
3. El usuario cambia su contraseña en la página específica de la aplicación haciendo que la aplicación llame a la Auth0 Management API
4. Una vez que el usuario haya cambiado correctamente su contraseña, la aplicación extrae la reclamación authorize_again del JWT verificado y decodificado, y luego redirige al usuario a esa URL para que pueda iniciar sesión con su nueva contraseña.

function(user, context, callback) {
   /*
   * Requisitos previos:
   * 1. Implementar una función `mustChangePassword`
   * 2. Establecer variables de configuración para lo siguiente:
   *    - CLIENT_ID
   *    - CLIENT_SECRET
   *    - ISSUER
   */

  const url = require('url@0.10.3');
  const req = context.request;

  function mustChangePassword() {
    // TODO: implementar la función
    return true;
  }

  if (mustChangePassword()) {
    // El usuario ha iniciado sesión y debe cambiar su contraseña
    // Enviar la información del usuario y los parámetros de consulta en un JWT para evitar manipulaciones
    function createToken(clientId, clientSecret, issuer, user) {
      const options = {
        expiresInMinutes: 5,
        audience: clientId,
        issuer: issuer
      };
      return jwt.sign(user, clientSecret, options);
    }

    const token = createToken(
      configuration.CLIENT_ID,
      configuration.CLIENT_SECRET,
      configuration.ISSUER,
      {
        sub: user.user_id,
        email: user.email,
        authorize_again: url.format({
          protocol: 'https',
          hostname: auth0.com,
          pathname: '/authorize',
          query: req.query
        })
      }
    );

    context.redirect = {
      url: `https://example.com/change-pw?token=${token}`
    };
  }

  return callback(null, user, context);
}

​

Dónde almacenar datos

Evita almacenar demasiados datos en el perfil de Auth0. Estos datos están pensados para fines de autenticación y autorización. Las capacidades de metadatos y búsqueda de Auth0 no están diseñadas para estudios de marketing ni para otros casos que requieran búsquedas intensivas o actualizaciones frecuentes. Es probable que tu sistema tenga problemas de escalabilidad y rendimiento si usas Auth0 con ese fin. Una mejor opción es almacenar los datos en un sistema externo y guardar un puntero (el id del usuario) en Auth0 para que los sistemas de backend puedan obtener esos datos si es necesario. Una regla sencilla que debes seguir es almacenar solo los elementos que tengas previsto usar en Rules para añadirlos a los tokens o tomar decisiones.

​

Consideraciones de seguridad

Pasar información de un lado a otro por el canal frontal amplía la superficie de ataque para los actores maliciosos. Esto solo debe hacerse cuando sea imprescindible actuar en la Rule (por ejemplo, rechazar el intento de autorización con UnauthorizedError).

Sin embargo, si necesitas comunicarte directamente con Auth0 y darle instrucciones para restringir el acceso (si estás implementando comprobaciones de captcha o MFA personalizada), debes contar con un mecanismo seguro para indicar a Auth0 que se cumplieron los requisitos de esa operación. Del mismo modo, si necesitas pasar información a la aplicación a la que estás redirigiendo, debes contar con una forma segura de garantizar que la información transferida no haya sido manipulada.

​

Asegúrese de que la aplicación inicie sesión como el mismo usuario

La aplicación va a redirigir al usuario de vuelta al inquilino de Auth0, por lo que cualquier dato relacionado con el usuario puede recopilarse a través del token de ID que se devuelve a la aplicación. Sin embargo, es posible que quiera asegurarse de que la aplicación inicie sesión como el mismo usuario que está siendo redirigido, para garantizar que no haya ningún tipo de manipulación durante el proceso. Por lo tanto, probablemente querrá enviar un token junto con la solicitud.

El token enviado a la aplicación debe cumplir los siguientes requisitos:

Elemento del token	Descripción
sub	El user_id de Auth0 del usuario.
iss	Un identificador que identifica a la propia Rule.
aud	La aplicación de destino de la redirección.
jti	Una cadena generada aleatoriamente que se almacena para su confirmación en el objeto de usuario (en el código de la Rule, establezca user.jti = uuid.v4(); y luego añádalo como jti al token que cree). user.jti seguirá establecido cuando las Rules se ejecuten de nuevo al llamar a /continue. Esto se ajusta a las especificaciones.
exp	Debe ser lo más corto posible para evitar la reutilización del token.
other	Cualquier otra información de claims personalizados que necesite pasar.
signature	Suponiendo que la aplicación tenga un lugar seguro donde almacenar un secreto, puede usar firmas con HS256. Esto reduce en gran medida la complejidad de la solución y, dado que el token que se devuelve también tendrá que estar firmado, este es un requisito de esta solución. Puede usar RS256, pero requiere crear un certificado y actualizarlo cuando expire. Si no está devolviendo ninguna información directamente a las Rules, podría usar una SPA para esta aplicación intermedia y quizá prefiera RS256 para que la aplicación no tenga que almacenar la información. Para ello, necesitaría una forma de validar el token, ya sea mediante un endpoint de introspección o un endpoint JWKS público.

Este token no debe tratarse como un token Bearer. Es una pieza de información firmada para usarse en la aplicación. La aplicación igualmente debe redirigir de vuelta a Auth0 para autenticar al usuario.

​

Devolver información a la Rule

En la mayoría de los casos, incluso si quiere pasar información de la Rule a la aplicación, lo ideal es que la aplicación pueda almacenarla de forma segura en el mecanismo de almacenamiento que corresponda. Incluso si lo que se pretende es actualizar los metadatos de la aplicación o del usuario en Auth0, eso puede hacerse mediante la Management API, y la información del usuario se actualizará siempre que esto se complete antes de redirigirlo de vuelta al endpoint /continue. Solo debería devolver información a la Rule si es la propia Rule la que necesita obtenerla y si esa información solo es relevante para esta sesión de inicio de sesión en particular.

Al devolver información al endpoint /continue, el token enviado debe cumplir los siguientes requisitos:

Elemento del token	Descripción
sub	El user_id de Auth0 del usuario.
iss	La aplicación de destino de la redirección.
aud	Algún identificador que identifique a la propia Rule.
jti	El mismo JTI que se almacenó en el token pasado a la aplicación (NOTA: debe coincidir con user.jti; de lo contrario, debe fallar).
exp	Debe ser lo más breve posible para evitar la reutilización del token.
other	Cualquier otra información de claims personalizada que necesite pasar.
signature	Suponiendo que la aplicación disponga de un lugar seguro para almacenar un secreto, puede usar firmas con HS256. Esto reduce considerablemente la complejidad de la solución y, dado que el token que se devuelve también tendrá que estar firmado, este es un requisito de esta solución. Puede usar RS256, pero requiere crear un certificado y actualizarlo cuando caduque.

Debe enviarse mediante POST y luego recuperarse en context.request.body.token (o algo similar), en lugar de pasarlo como parámetro de consulta. Esto es similar al método form-post para autenticación.

Si no está devolviendo información al endpoint /continue, quizá le convenga añadir el JTI a una lista de denegación, a menos que los tiempos de expiración sean lo suficientemente cortos como para que los ataques de repetición sean casi imposibles.

​

Restricciones y limitaciones

Las Redirect Rules no funcionan con:

• endpoint de Resource Owner
• intercambio de contraseña
• intercambio de Token de actualización

Puede identificar los casos anteriores comprobando context.protocol:

• Para el intercambio de contraseña: context.protocol === 'oauth2-password'
• Para el intercambio de Token de actualización: context.protocol === 'oauth2-refresh-token'
• Para los inicios de sesión con Resource Owner: context.protocol === 'oauth2-resource-owner'

​

Tiempo de espera de sesión

Las sesiones de las Rules de redirección suelen ser válidas durante 3 días, a menos que haya configurado un tiempo de espera más corto en la configuración de Gestión de sesiones de inicio de sesión. Puede encontrar esta configuración en la configuración avanzada de su inquilino.

​

Endpoint de Resource Owner

No es posible usar Rules de redirección en el contexto en el que llamas directamente a /oauth/token para el flujo Resource Owner Password Grant. Como el usuario no forma parte de un flujo de redirección desde el principio, no puedes redirigirlo en una Rule. Si intentas establecer context.redirect, obtendrás un intento de inicio de sesión fallido con el error interaction_required.

​

Flujos con prompt=none

Dado que el objetivo de prompt=none es evitar cualquier escenario en el que el usuario tenga que introducir información, cualquier redirección dará lugar a un error=interaction_required.

Como las Rules se ejecutan después de que se crea una sesión de autenticación, no puede usar prompt=none si tiene una Rule de redirección que intenta bloquear el acceso a los tokens en determinadas condiciones (MFA personalizada, captcha en el inicio de sesión, etc.).

No puede crear un flujo de redirección que bloquee el acceso a los tokens y omita la Rule de redirección con prompt=none porque, después de un intento fallido, un usuario puede simplemente volver a hacer la llamada con prompt=none y obtener tokens, ya que su sesión de autenticación ya se habrá creado aunque las Rules hayan fallado la primera vez.

​

Tokens de actualización

Dado que usar un token de actualización requiere una llamada por canal secundario a /oauth/token, esto también fallará si se establece context.redirect.

Es difícil verificar de forma segura que se hayan aplicado las restricciones del inicio de sesión. No hay un ID de sesión consistente en el contexto que pueda usarse para recopilar información asociada con la sesión, por ejemplo, si este usuario superó las verificaciones de MFA. Por lo tanto, no puede usar prompt=none en absoluto.

Cada vez que se establece context.redirect en una Rule, si se pasó prompt=none, la autorización falla con error=interaction_required, pero como la sesión del usuario se crea incluso si las Rules fallan, no podemos confiar en que un usuario haya superado todas las verificaciones de context.redirect y, por lo tanto, no podemos usar prompt=none como una forma de obtener tokens.

En este caso específico, le recomendamos usar exclusivamente tokens de actualización, porque así puede asegurarse de que un usuario haya superado las verificaciones si estas son necesarias para generar un token de actualización.

​

Más información

• Redirigir a los usuarios
• Comprender cómo funciona el perfilado progresivo
• Redirigir a los usuarios mediante un cierre de sesión alternativo