Saltar al contenido principal

La disponibilidad varía según el plan de Auth0

Tanto tu implementación específica de inicio de sesión como tu plan de Auth0 o acuerdo personalizado determinan si esta característica está disponible. Para obtener más información, consulta Pricing.

​
Casos de uso empresariales

La funcionalidad de Organizaciones de Auth0 es especialmente adecuada para implementaciones de empresa a empresa (B2B) con aplicaciones a las que acceden los usuarios finales.
Diagrama del caso de uso empresarial de Organizaciones B2B
Las características habituales de las implementaciones B2B incluyen:
  • Un producto que se licencia a otra empresa para que lo utilicen sus empleados.
  • Cada organización requiere su propia federación y una marca básica para la experiencia de autenticación.
  • Los niveles de acceso en la aplicación pueden representarse mediante roles asignados a los miembros de cada organización.
Veamos algunos casos de uso empresariales de ejemplo para destacar cómo pueden ayudar las Organizaciones.

​
Escenario de ejemplo

Travel0 es una empresa ficticia que ofrece servicios de viajes en línea y ha configurado un inquilino de Auth0. Travel0 tiene varias aplicaciones, pero nos centraremos en una que podría beneficiarse del uso de Organizaciones. Travel0 Adventure Management: Una aplicación en línea que permite a sus clientes crear y promocionar aventuras, como rafting en aguas bravas, paseos a caballo y tirolesa. Cada aventura está dirigida por un guía que puede usar la aplicación para registrarse y gestionar los horarios. Los guías pueden ser empleados directamente por el cliente o trabajar como freelance. Los clientes de la aplicación incluyen:
  • Granite Outpost Rafting and Ziplines: Una empresa consolidada que emplea directamente a una gran plantilla de guías, aunque a veces también recurre a guías freelance. Tienen su propio que usan para sus empleados.
  • AdventureZ: Una gran empresa de eventos que emplea directamente a un gran número de guías, pero que también usa freelancers, aunque rara vez. Además, facilita que sus empleados directos puedan trabajar como freelance para otras empresas que necesiten guías. Tienen su propio IdP que usan para sus empleados.
  • Rocky Mountain High Adventures: Una empresa nueva que apenas está entrando en el mercado. Los cofundadores dirigen la mayoría de sus recorridos y recurren a freelancers para obtener ayuda en los periodos de mayor actividad. No tienen personal de TI, ni el tiempo ni la disposición para configurar su propio proveedor de identidad (IdP). Tienen un contrato con AdventureZ que permite que cualquier empleado de AdventureZ trabaje como freelance para ellos.

​
Consideraciones de planificación

Al configurar organizaciones, tenga en cuenta lo siguiente:
  • Experiencia de inicio de sesión: ¿Se requerirá que los usuarios seleccionen una organización al iniciar sesión? ¿Verán los usuarios la página de inicio de sesión predeterminada de la aplicación o una página de inicio de sesión personalizada para su organización?
  • Modelo de conexión: ¿Se compartirán usuarios entre organizaciones? ¿Necesitan los usuarios poder iniciar sesión con el Proveedor de identidad interno de una organización?
  • Roles: ¿La aplicación requiere que los usuarios tengan roles específicos asignados dentro de sus organizaciones? ¿Tiene previsto crear un panel personalizado que permita a los administradores gestionar sus organizaciones por sí mismos mediante los roles asignados?

​
Experiencia de inicio de sesión

En primer lugar, debe decidir qué experiencia debe tener el usuario cuando inicie sesión en una organización. Puede optar por enviar al usuario final directamente a la pantalla de inicio de sesión de una Organización específica en Auth0, o bien enviarlo a una pantalla en la que pueda introducir el nombre de la Organización con la que quiere iniciar sesión. Además, debe elegir si desea usar la página predeterminada de configurada para su aplicación o personalizar una página de inicio de sesión específica para cada organización mediante plantillas de página. Para obtener más información, consulte Create Your First Organization.

​
Modelo de conexión

Cada organización normalmente se corresponderá directamente con uno de sus clientes empresariales o socios, pero los usuarios pueden ser miembros de varias organizaciones. Comprender cómo se corresponden los usuarios con las organizaciones de clientes le ayudará a determinar cómo modelar sus organizaciones y conexiones. Hay dos escenarios de usuario:
  • Los usuarios están aislados en una organización: Cada usuario es miembro de exactamente una organización. O bien los usuarios nunca necesitarán formar parte de varias organizaciones, o bien tendrá más sentido que creen una identidad independiente para cada organización.
  • Los usuarios se comparten entre organizaciones: Cualquier usuario puede pertenecer a varias organizaciones y debe poder usar la misma identidad para navegar entre ellas.
Usando nuestro ejemplo de Travel0 Adventure Management, supongamos los siguientes usuarios:
  • Jonno: Un guía empleado directamente por Rocky Mountain High Adventures que solo debe poder iniciar sesión en la organización de Rocky Mountain. Como Rocky Mountain no tiene su propio IdP, las credenciales de Jonno se almacenan en la conexión de base de datos de Travel0 y a Jonno se le asigna pertenencia a la organización Rocky Mountain.
  • Hiroko: Una guía empleada directamente por Granite Outpost Rafting and Ziplines que solo debe poder iniciar sesión en la organización de Granite Outpost. Como Granite Outpost tiene su propio IdP, las credenciales de Hiroko pueden almacenarse en la conexión de base de datos de Travel0 o en una conexión empresarial que Granite Outpost haya configurado para representar su IdP, y además debe asignarse a Hiroko pertenencia a la organización de Granite Outpost. Si se usa el IdP de Granite Outpost, la conexión empresarial también debe habilitarse para la organización.
  • Emilio: Un guía autónomo que trabaja tanto para Rocky Mountain High Adventures como para Granite Outpost Rafting and Ziplines y debe poder iniciar sesión en ambas organizaciones. Si queremos que Emilio pueda usar las mismas credenciales para ambas organizaciones, entonces sus credenciales deben almacenarse en la conexión de base de datos de Travel0, y debe asignársele pertenencia a las organizaciones Rocky Mountain y Granite Outpost. De lo contrario, Emilio deberá configurar un juego de credenciales en la conexión de base de datos de Travel0 para Rocky Mountain High Adventures y recibir pertenencia a la organización Rocky Mountain High, y luego configurar otro juego de credenciales en la conexión de base de datos de Travel0 o en la conexión empresarial de Granite Outpost, y recibir pertenencia a la organización Granite Outpost. Por último, si se usa el IdP de Granite Outpost, la conexión empresarial configurada debe habilitarse para la organización Granite Outpost.
  • Sumana: Una guía empleada directamente por AdventureZ, pero que a veces trabaja como autónoma para Rocky Mountain High Adventures en virtud del contrato que Rocky Mountain tiene con AdventureZ. AdventureZ y Rocky Mountain tienen sistemas de calificación para sus guías, y las calificaciones de Sumana deben transferirse de AdventureZ a Rocky Mountain y combinarse entre organizaciones. Las credenciales de Sumana deben almacenarse en la conexión de base de datos de Travel0 y debe asignársele pertenencia a las organizaciones Rocky Mountain y AdventureZ o, si AdventureZ quiere compartir su IdP, sus credenciales deben almacenarse en una conexión empresarial que AdventureZ haya configurado para representar su IdP y la conexión empresarial configurada debe habilitarse para las organizaciones Rocky Mountain y AdventureZ. Si Sumana también es invitada a trabajar como autónoma para Granite Outpost Rafting and Ziplines, entonces sus credenciales podrían almacenarse en la conexión de base de datos de Travel0 o podría agregarse al IdP de Granite Outpost, y debe asignársele pertenencia a la organización Granite Outpost.
Una vez que haya determinado cuántas organizaciones tendrá y cómo debe ser su modelo de conexión, puede configurar conexiones de base de datos, sociales o empresariales; crear organizaciones; y configurar la pertenencia a la organización o habilitar conexiones de la organización.

​
Roles

A los miembros de las organizaciones se les pueden asignar roles. Puede usar estos roles para definir el control de acceso de su aplicación. Por ejemplo, si creó un panel para sus usuarios con nuestra API y nuestros SDK, podría asignar un rol de administrador a determinados miembros y permitirles autoadministrar sus organizaciones desde ese panel.
Se debe acceder a Management API únicamente mediante un cliente confidencial. Su uso está sujeto a los límites de tasa de la Auth0 Management API.

​
Limitaciones

La funcionalidad Organizaciones de Auth0 tiene las siguientes limitaciones:
  • La disponibilidad de esta funcionalidad depende de su plan de suscripción de Auth0. Para obtener más información, consulte Auth0 Pricing.
  • Solo es compatible con Universal Login (no es compatible con Classic Login ni con Lock.js).
  • Las aplicaciones con organizaciones habilitadas no son compatibles con los siguientes grants y protocolos: Password, Device , (Auth0 como IdP).
  • No admite:
    • Dominios personalizados por organización (Por ejemplo, en el escenario de ejemplo, si Rocky Mountain High Adventures y Granite Outpost Rafting and Ziplining pudieran usar login.travel0.com como dominio de inicio de sesión, Organizaciones sería útil. En cambio, si Rocky Mountain High Adventures quisiera usar login.rockymountain.com y Granite Outpost quisiera usar login.graniteoutpost.com, tendría que usar varios inquilinos de Auth0.
    • Integración con la extensión Delegated Administration.
    • Integración con la extensión Authorization.
    • Integración con aplicaciones de terceros.

​
Más información