Saltar al contenido principal
Al utilizar la funcionalidad Organización de Auth0, se puede aprovisionar un único Tenant de Auth0 para su implementación en un entorno de producción. Salvo en los escenarios arquitectónicos más complejos, se recomienda aprovisionar un único Tenant de Auth0 para su uso en un entorno de producción, ya que simplifica la integración y el uso de inicio de sesión único (SSO), la gestión de perfiles de usuario, etc. Según la implementación, deberá tener en cuenta algunos aspectos adicionales relacionados con la configuración de su Tenant de Auth0 y de la integración correspondiente. La marca asociada a una organización es extremadamente valiosa, ya que el uso de recursos de marca proporciona a los usuarios un entorno que conocen y en el que confían. El uso de recursos de marca reconocibles también aumenta la confianza de los usuarios en que la información que proporcionan (por ejemplo, las credenciales) se gestionará de forma segura. Por lo tanto, la marca predeterminada de Auth0 debe sustituirse. Para obtener más información, consulte Marca.

​
Organizaciones

Debe crear una Organización de Auth0 independiente para cada una de las organizaciones a las que dará soporte. En este caso, crearemos la organización hoekstra para representar a Hoekstra & Associates en nuestro ejemplo y la organización metahexa para representar a MetaHexa Bank. Puede crear organizaciones manualmente a través del o de forma programática mediante la de Auth0.

​
Aplicaciones

Según cómo esté diseñada la implementación de su Tenant de Organización, tiene distintas opciones al crear definiciones de Aplicación dentro de su Tenant de Auth0. Independientemente de la opción que elija, el comportamiento de la Organización se define a nivel de la aplicación. Si aprovisiona un Tenant de Organización independiente para cada uno de sus clientes, normalmente necesitará una definición de Aplicación independiente en Auth0 para cada uno. Esta configuración también suele implicar enviar tanto el parámetro client_id específico de la Aplicación como el parámetro organization, que identifica qué Organización de Auth0 se debe usar, como parte de la llamada al endpoint /authorize. Para obtener más información, consulte Autenticación.
Práctica recomendadaPara facilitar la configuración y maximizar el aislamiento de seguridad, defina las Aplicaciones en Auth0 de forma independiente. Esto permite configurar de manera independiente elementos como las URL de callback permitidas y, siguiendo el principio de privilegio mínimo, minimiza la posible exposición de información como el ID de cliente y el Secreto del cliente.
Como alternativa, se admite el uso de una única definición de Aplicación en Auth0. En este caso, se pedirá al usuario que especifique la organización requerida como parte de la autenticación del primer factor. Esto normalmente requerirá el uso de un client_id de Aplicación común, pero el parámetro organization se omitirá en la llamada al endpoint /authorize.

​
Conexiones

A continuación, defina las Conexiones que se utilizarán para autenticar a los usuarios. En este caso, definiremos una Conexión de base de datos para los usuarios asociados con Hoekstra & Associates y una conexión empresarial para los usuarios asociados con MetaHexa Bank.
Práctica recomendadaPara las Organizaciones con un único Proveedor de identidad (IdP), cree una Conexión para cada organización definida a fin de ofrecer flexibilidad para distintos casos de uso. Por ejemplo, una sola Conexión de base de datos o Conexión de base de datos personalizada por organización le permite eliminar fácilmente a los usuarios asociados con organizaciones que se retiran y ofrece la máxima flexibilidad para las organizaciones que tienen distintos requisitos de complejidad de contraseña.
Una vez definida la Conexión, puede configurarse para la Organización de Auth0 correspondiente mediante Auth0 Dashboard o Auth0 Management API. Para obtener más información, consulte Habilitar conexiones de organización.

​
Usuarios

En el caso de los usuarios que se autentican mediante conexiones distintas de Conexiones de base de datos o Conexiones de base de datos personalizadas, el usuario se aprovisiona en el (IdP) externo, de forma independiente de Auth0 y de la manera habitual. Por otro lado, los usuarios que se autentican mediante Conexiones de base de datos o Conexiones de base de datos personalizadas pueden aprovisionarse de diferentes maneras. Auth0 Dashboard y Auth0 Management API pueden utilizarse para crear un usuario directamente en su Tenant de Auth0. También admitimos la migración automática y la migración masiva.
Para que un usuario se aprovisione mediante Management API o Dashboard, debe habilitar directamente una Conexión de base de datos o Conexión de base de datos personalizada para al menos una aplicación. No basta con habilitar una Conexión de base de datos o Conexión de base de datos personalizada solo para una organización.
A continuación, los usuarios se asocian a una Organización de Auth0 asignándoles membresías, y una Organización de Auth0 puede configurarse para asignar automáticamente la membresía de usuario o hacerlo manualmente.
Para asignar manualmente una membresía a una organización, ese usuario ya debe tener un perfil de usuario definido en Auth0. Puede asignar la membresía manualmente mediante Auth0 Dashboard del Tenant o Auth0 Management API.

​
Invitación

La funcionalidad de Organización de Auth0 también admite invitaciones a miembros. En el flujo de trabajo de invitación a miembros, al invitar a un usuario a una aplicación, el usuario se aprovisiona automáticamente y su membresía se genera también de forma automática.

​
Conexión de base de datos

Tomando como ejemplo Hoekstra & Associates, veamos cómo podría funcionar esta implementación cuando se utiliza una Conexión de base de datos como parte de una invitación de usuarios; normalmente, la mayor parte del flujo de trabajo descrito se gestionará mediante el SDK o la biblioteca de Auth0 correspondientes a su pila tecnológica:
Escenarios de arquitectura - MOA - Usuarios aislados, aplicaciones compartidas, flujo de invitación (Conexión de base de datos)
  1. Jennifer de Hoekstra & Associates recibe un correo electrónico enviado desde el Tenant de Auth0 de Travel0 en nombre de la instancia de Travel0 Corporate Booking de Hoekstra & Associates.
    1. El correo electrónico se envió como se describe en Invitar a miembros de la organización y puede que se haya activado desde el Auth0 Dashboard o la Auth0 Management API.
  2. Jennifer abre el correo electrónico y hace clic en el enlace incluido. Al hacerlo, su navegador se redirige a la instancia de Travel0 Corporate Booking de Hoekstra & Associates. La URL base utilizada en el enlace se especifica como el URI de Login de la aplicación, que forma parte de la definición de la aplicación Travel0 Corporate Booking para la instancia de Hoekstra & Associates en el Tenant de Auth0 de Travel0.
    1. El enlace contiene los parámetros organization y organization_name. El parámetro organization se establece con el id de la definición correspondiente de la Organización de Auth0 en su tenant de Auth0. Este valor se reenviará al tenant de Auth0 como parte del paso 3.
    2. El enlace también contiene el parámetro invitation, que también se reenviará como parte del paso 3.
  3. 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), al llamar al endpoint /authorize y pasar parámetros similares a los siguientes, normalmente mediante 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: state único generado en esta sesión
    4. scope: openid profile …
    5. cualquier OIDC Scopes adicional necesario, según la información que se requiera sobre el usuario.
    6. client_id: ID de cliente asociado a la aplicación creada en el Tenant de Auth0 de Travel0 para la instancia de Travel0 Corporate Booking de Hoekstra & Associates.
    7. organization: ID de la organización que invita, que normalmente se obtiene a través del enlace del correo electrónico descrito en el paso 2. Se especifica con el formato organization=organization_id, donde organization_id se establece con el identificador asociado a la definición correspondiente de Organización de Auth0 en tu Tenant de Auth0.
    8. invitation: Parámetro invitation adicional asociado al enlace del correo electrónico, como se describe en el paso 2.
  4. El Tenant de Auth0 de Travel0 redirige a /signup/invitation para que el usuario establezca una contraseña.
    1. Se muestra una página de Universal Login, que puede configurar para mostrar elementos de marca específicos de la organización, como se describe en Marca.
      El flujo de trabajo de invitación asociado con la característica Organizations de Auth0 no tiene en cuenta ninguna sesión de SSO activa en Auth0. Si se invita a un usuario a registrarse y ya ha iniciado sesión, al hacer clic en el enlace del correo electrónico siempre se mostrará la página de Universal Login asociada.
  5. El usuario introduce su contraseña (y cualquier credencial adicional, como el nombre de usuario) y hace clic en Continuar. El ID de usuario se establece en la dirección de correo electrónico asociada al usuario y no se puede cambiar.
  6. El Tenant de Auth0 de Travel0 verifica las credenciales. Si son válidas, se aprovisiona al usuario y se le asigna la membresía de la Organización de Auth0. El usuario se autentica de forma implícita y se ejecuta el flujo de Rules. Rules pueden usarse para gestionar el control de acceso, como se describe en Autorización.
    1. Si las credenciales del usuario no son válidas, se le pedirá que las vuelva a introducir.
  7. Tras verificar correctamente las credenciales y ejecutar Rules, se redirige al usuario al redirect_uri (https://hoekstra.corp.travel0.net/login/callback) con el state enviado en el paso 3, así como con un code.
  8. 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 junto con su client id y client secret a cambio del ID Token. Luego, el ID token se utiliza para generar una sesión en https://hoekstra.corp.travel0.net.
  9. La instancia de Travel0 Corporate Booking de Hoekstra & Associates muestra al usuario la página correspondiente.

​
Conexión empresarial

Usando nuestro ejemplo de MetaHexa Bank, veamos cómo podría desarrollarse esta implementación cuando se usa una conexión empresarial como parte de la invitación de usuarios; 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 invitación (conexión empresarial)
  1. Amintha de MetaHexa Bank recibe un correo electrónico enviado desde el Tenant de Auth0 de Travel0 en nombre de la instancia de Travel0 Corporate Booking de MetaHexa Bank.
    1. El correo electrónico se envió como se describe en Invitar a miembros de la organización y puede haberse desencadenado mediante el Auth0 Dashboard o la Auth0 Management API.
  2. Amintha abre el correo electrónico y hace clic en el enlace que contiene. Al hacerlo, su navegador se dirige a la instancia de Travel0 Corporate Booking de MetaHexa Bank. La URL base usada en el enlace se especifica como el URI de inicio de sesión de la aplicación, que forma parte de la definición de la aplicación de la instancia de Travel0 Corporate Booking de MetaHexa Bank en el Tenant de Auth0 de Travel0.
    1. El enlace contiene los parámetros organization y organization_name. El parámetro organization se establece en el ID de la definición correspondiente de la Organización de Auth0 en su Tenant de Auth0. Esto se reenviará al Tenant de Auth0 como parte del paso 3.
    2. El enlace también contiene el parámetro invitation, que igualmente se reenviará como parte del paso 3.
  3. La instancia de Travel0 Corporate Booking de MetaHexa Bank redirige al Tenant de Auth0 de Travel0 mediante el Flujo de código de autorización (con o sin PKCE) al llamar al endpoint /authorize y pasar parámetros similares a los siguientes, normalmente mediante 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 de OIDC adicional necesario, según la información requerida sobre el usuario. Véase también OIDC Scopes.
    6. client_id: ID de cliente asociado con la aplicación creada en el Tenant de Auth0 de Travel0 para la instancia de Travel0 Corporate Booking de MetaHexa Bank.
    7. organization: ID de la organización que invita, normalmente obtenido mediante el enlace del correo electrónico descrito en el paso 2. Se especifica con el formato organization=organization_id, donde organization_id se establece en el identificador asociado con la definición correspondiente de la Organización de Auth0 en su Tenant de Auth0.
    8. invitation: Parámetro invitation adicional asociado con el enlace del correo electrónico, como se describe en el paso 2.
  4. El Tenant de Auth0 de Travel0 redirige a /invitation, donde se informa a Amintha de que primero se la redirigirá al IdP de MetaHexa para autenticarse con las credenciales del primer factor.
    1. El usuario confirma, y
    2. Auth0 redirige a la instancia de IdP de MetaHexa Bank, donde
    3. Se muestra la página de inicio de sesión, y el usuario introduce las credenciales y hace clic en login.
  5. Si se completa correctamente, se establece la pertenencia a la Organización de Auth0, el usuario queda autenticado de forma implícita y se ejecuta el flujo de Rules. Rules puede usarse para gestionar el control de acceso como se describe en Autorización.
Los pasos del 6 al 8 coincidirán con los descritos en el escenario de Conexión de base de datos, pero Amintha será la usuaria en lugar de Jennifer, y se usará MetaHexa Bank (metahexa.corp.travel0.net) en lugar de Hoekstra & Associates.

​
Conexión social

La invitación mediante una conexión social sigue un patrón similar al de una conexión empresarial, pero el IdP de origen está asociado con el proveedor social, no con ninguna organización específica. Para conocer otras consideraciones sobre el uso de conexiones sociales, consulte Autenticación.