Saltar al contenido principal
En nuestros escenarios de arquitectura, proporcionamos orientación general sobre la Autenticación B2B, incluido el uso de Universal Login como práctica recomendada, cuya revisión te recomendamos junto con la orientación que se proporciona aquí.
Práctica recomendadaAunque Auth0 admite numerosos flujos de autenticación, los que usan Auth0 Universal Login se consideran una práctica recomendada tanto del sector como de Auth0 porque proporcionan funcionalidad y seguridad óptimas. En particular, Universal Login proporciona inicio de sesión único (SSO) listo para usar y ayuda a mitigar ataques como el phishing y bucket brigade; por esta razón, debe ser la opción preferida siempre que un usuario introduzca credenciales de contraseña. Además, la nueva experiencia de Universal Login también es el único mecanismo compatible al usar la funcionalidad Organizations de Auth0.
La autenticación de usuarios requiere procesar credenciales del primer factor. Tanto si esto lo realiza Auth0 como si lo hace un (IdP) de terceros, cuando utilizas la funcionalidad Organizations de Auth0 también debes usar la experiencia de Universal Login de Auth0.
Auth0 admite solo un contexto de usuario autenticado por inquilino de Auth0; los inquilinos no pueden cambiar selectivamente entre contextos de usuario autenticado. Cambiar el contexto de usuario afecta a cualquier sesión de SSO activa, y esto también se extiende a la funcionalidad Organizations de Auth0. Si los contextos por organización son absolutamente necesarios, será necesario desplegar varios inquilinos de Auth0 en producción. Dado que usar varios inquilinos tiene implicaciones que afectan al inicio de sesión único (SSO), a la gestión del perfil de usuario y a otros aspectos, debes evaluar cuidadosamente esta opción antes de seguir ese camino.

​
Conexión de base de datos

Con nuestro ejemplo de Hoekstra & Associates, veamos cómo podría desarrollarse esta implementación de autenticación con un usuario autenticado mediante una conexión de base de datos de Auth0; la mayor parte del flujo de trabajo descrito suele gestionarse con el SDK o la biblioteca de Auth0 correspondiente a su pila tecnológica:
Escenarios de arquitectura - MOA - Usuarios aislados, aplicaciones compartidas, flujo de Login con base de datos
  1. Jennifer, de Hoekstra & Associates, abre su navegador y accede a la instancia de Travel0 Corporate Booking de Hoekstra & Associates.
    1. Si Jennifer ya tiene una cookie de sesión con la instancia de Travel0 Corporate Booking de Hoekstra & Associates, normalmente ya habrá iniciado sesión en el sistema, y aquí finaliza el proceso. Para obtener más información, consulte Inicio de sesión único.
  2. La instancia de Travel0 Corporate Booking de Hoekstra & Associates redirige al Tenant de Auth0 de Travel0 mediante el Flujo de código de autorización (con o sin PKCE) llamando al endpoint /authorize y pasando parámetros, normalmente mediante el uso de un SDK de Auth0 o una biblioteca de terceros:
    1. redirect_uri: https://hoekstra.corp.travel0.net/login/callback
    2. response_type: code
    3. state: estado único generado en esta sesión
    4. scope: openid profile …
    5. cualquier alcance de OIDC adicional que sea necesario, según la información requerida sobre el usuario.
    6. client_id: ID de cliente asociado a la aplicación creada en el inquilino de Auth0 de Travel0 para la instancia de Travel0 Corporate Booking de Hoekstra & Associates.
    7. organization: Organización de Auth0 que se debe usar. Cuando la organización se conoce de antemano, una solicitud a /authorize puede incluir este parámetro, que se especifica con el formato organization=organization_id, donde organization_id se establece con el identificador asociado a la definición correspondiente de la Organización de Auth0 en tu inquilino de Auth0. Como alternativa, puedes omitir el parámetro organization de la llamada a /authorize y configurar tu inquilino de Auth0 para que solicite al usuario que seleccione la organización adecuada como parte de la autenticación del primer factor. Para obtener más información, consulta Definir el comportamiento de la organización.
      Si el parámetro organization se incluye en una llamada al endpoint /authorize, debe usarse de forma coherente durante toda la sesión con Auth0. La funcionalidad de Organizations no asocia ninguna organización seleccionada con la sesión de SSO de Auth0, por lo que, si omites el parámetro, siempre se solicitará al usuario que seleccione la organización deseada.
  3. El Tenant de Auth0 de Travel0 redirige a /login para solicitar las credenciales al usuario. Si Jennifer ya tiene una sesión de base de datos con Hoekstra & Associates, se omitirán los pasos 3a y 4. Para obtener más información, consulta inicio de sesión único (SSO).
    1. Se muestra la página de Universal Login, que puede configurar para incluir recursos de marca específicos de la organización, como se describe en Marca.
  4. El usuario introduce sus credenciales y hace clic en login.
  5. El Tenant de Auth0 de Travel0 comprueba las credenciales del usuario; si son válidas, se ejecuta el flujo de Rules. Rules se puede usar para gestionar el control de acceso, como se describe en Autorización. Si las credenciales del usuario no son válidas, se le pedirá que vuelva a introducirlas.
    La asignación automática de membresía se realizará si se ha especificado esta opción. Para obtener más información, consulta Conceder membresía Just-In-Time a una Conexión de Organización. En el caso de la membresía asignada manualmente, la validación fallará si el usuario no ha sido asignado previamente como miembro de la Organización.
  6. Tras una autenticación correcta del primer factor y la ejecución de Rules, se redirige al usuario a redirect_uri (https://hoekstra.corp.travel0.net/login/callback) con el state enviado en el paso 2, así como un code.
  7. La instancia de Travel0 Corporate Booking de Hoekstra & Associates valida el state y luego llama al Tenant de Auth0 de Travel0 en https://auth.travel0.net/oauth/token, pasando el code, su ID de cliente y su Secreto del cliente para obtener el ID Token. Luego, el ID Token se usa para generar una sesión para https://hoekstra.corp.travel0.net.
  8. La instancia de Travel0 Corporate Booking de Hoekstra & Associates muestra al usuario la página adecuada.

​
Conexión empresarial

La autenticación mediante una conexión empresarial sigue un proceso muy similar. Con nuestro ejemplo de MetaHexa Bank, veamos cómo podría desarrollarse esta implementación de autenticación con un usuario autenticado mediante la conexión empresarial de MetaHexa Bank; nuevamente, la mayor parte del flujo de trabajo descrito normalmente se gestionará mediante el SDK o la biblioteca de Auth0 correspondientes a su stack tecnológico.
Escenarios de arquitectura - MOA - Usuarios aislados, aplicaciones compartidas, flujo de Login empresarial
  1. Amintha, de MetaHexa Bank, abre su navegador y accede a la instancia de Travel0 Corporate Booking de MetaHexa Bank.
    1. Si Amintha ya tiene una cookie de sesión con la instancia de Travel0 Corporate Booking de MetaHexa Bank, normalmente iniciará sesión en el sistema y el proceso terminará aquí. Para obtener más información, consulte Inicio de sesión único.
  2. La instancia de Travel0 Corporate Booking de MetaHexa Bank redirige al inquilino de Auth0 de Travel0 mediante el Flujo de código de autorización (con o sin PKCE) llamando al endpoint /authorize y pasando parámetros, normalmente mediante el uso de un SDK de Auth0 o una biblioteca de terceros:
    1. redirect_uri: https://metahexa.corp.travel0.net/login/callback
    2. response_type: code
    3. state: estado único generado en esta sesión
    4. scope: openid profile …
    5. cualquier alcance adicional de OIDC Scopes necesario, según la información requerida sobre el usuario.
    6. client_id: ID de cliente asociado a la aplicación creada en el inquilino de Auth0 de Travel0 para la instancia de Travel0 Corporate Booking de MetaHexa Bank.
    7. organization: Organización de Auth0 que se va a usar. Cuando la organización se conoce de antemano, una solicitud a /authorize puede incluir este parámetro, que se especifica con el formato organization=organization_id, donde organization_id se establece en el identificador asociado a la definición correspondiente de la Organización de Auth0 en su inquilino de Auth0. Como alternativa, puede omitir el parámetro organization de la llamada a /authorize y configurar su inquilino de Auth0 para pedir al usuario que seleccione la organización adecuada como parte de la autenticación del primer factor. Para obtener más información, consulte Definir el comportamiento de la organización.
      Si el parámetro organization se incluye en una llamada al endpoint /authorize, debe usarse de forma coherente durante toda la sesión con Auth0. La funcionalidad Organizations no asocia ninguna organización seleccionada con la sesión de SSO de Auth0, por lo que omitir el parámetro siempre hará que se pida al usuario que seleccione la organización deseada.
    8. connection: nombre de la conexión empresarial de Auth0 configurada para MetaHexa Bank.
      Práctica recomendadaProporcione siempre el parámetro connection. Cuando no se proporciona, se pide al usuario que seleccione la conexión empresarial asociada al Proveedor de identidad (IdP) correspondiente, lo que añade un paso adicional desde la perspectiva de la experiencia de usuario.
  3. El inquilino de Auth0 de Travel redirige al IdP de MetaHexa para autenticar las credenciales del primer factor.
    1. Se muestra la página de inicio de sesión y el usuario introduce sus credenciales. Si Amintha ya tiene una sesión con el IdP de MetaHexa, se omitirán los pasos 3a y 4. Para obtener más información, consulte Inicio de sesión único (SSO).
  4. El usuario introduce sus credenciales y hace clic en login.
  5. Tras una autenticación correcta del primer factor, se ejecuta la canalización de Rules. Rules puede usarse para gestionar el control de acceso como se describe en Autorización. Si las credenciales del usuario no son válidas, se le pedirá que las vuelva a introducir.
La asignación automática de membresía se realizará si se ha especificado esta opción. Para obtener más información, consulte Otorgar membresía Just-In-Time a una conexión de organización. En el caso de la membresía asignada manualmente, la validación fallará si el usuario aún no ha sido asignado como miembro de la organización.
Los pasos del 6 al 8 coincidirán con los descritos en el escenario de Conexión de base de datos, pero con Amintha como usuario en lugar de Jennifer, y con MetaHexa Bank (metahexa.corp.travel0.net) en lugar de Hoekstra & Associates.

​
Conexión social

La autenticación mediante una conexión social sigue un patrón similar al de una conexión empresarial, pero en este caso el IdP de origen está asociado al proveedor social en lugar de a una organización específica.
Las conexiones sociales de Auth0 se definen a nivel de inquilino. Normalmente, se configura solo una conexión social por proveedor social en cada inquilino de Auth0, lo que significa que la definición se aplica al inquilino de Auth0 en su conjunto. Por lo tanto, cualquier consentimiento otorgado por un usuario se aplicará a todas las organizaciones de Auth0 definidas en un inquilino de Auth0, y no a una organización concreta.
Con las conexiones sociales, el aislamiento de usuarios no puede modelarse de forma coherente por organización. Aunque puede resultar tentador modelar el aislamiento de usuarios creando varias conexiones a un proveedor social, por ejemplo mediante conexiones sociales personalizadas, debe evitar hacerlo; esta estrategia puede hacer que se cree el mismo id de usuario en varias definiciones de conexión, lo que inevitablemente acabará causando problemas más adelante.