Cómo funciona la autenticación en su implementación de B2B IAM.
Para poder prestar servicios a sus usuarios, debe poder identificar quiénes son. Este proceso se denomina autenticación de usuarios. Existen varias formas de autenticar a un usuario: mediante cuentas de redes sociales, nombre de usuario y contraseña, y, a menudo, se recomienda ir más allá de un primer factor para autenticar al usuario habilitando la (MFA).
Es importante tener en cuenta tanto la seguridad como la experiencia del usuario al diseñar cómo autenticará a sus usuarios. Ofrecer varios factores primarios y/o exigir más de un factor durante la autenticación son formas de lograr ambas.
Hay varios aspectos que querrá tener en cuenta al evaluar la funcionalidad y el flujo de trabajo:
¿Dónde introducirán los usuarios sus credenciales?
¿Cómo mantendrá seguras las credenciales de los usuarios?
¿Cómo mantendrá su sistema de autenticación?
¿Cómo puede ofrecer autenticación con contraseña a sus usuarios?
¿Cómo puede evitar que los atacantes intenten iniciar sesión como sus usuarios?
¿Cómo implementará la autenticación en distintos tipos de aplicaciones?
¿Cómo puede facilitar el inicio de sesión a sus usuarios cuando provienen de distintos entornos lingüísticos?
¿Cómo ofrecerá una buena experiencia de usuario mientras migra desde cualquier sistema de autenticación heredado?
¿Qué debe tener en cuenta al integrar aplicaciones con Auth0?
¿Necesita ofrecer autenticación multifactor?
¿Qué hace si tiene un servicio que no ofrece una forma de que el usuario inicie sesión de antemano?
¿Puede pasar el mismo de usuario de una API a otra?
¿Qué hace si necesita aislar a los usuarios por organización?
¿Cómo gestionará la identificación de la organización a la que pertenecen los usuarios?
¿Qué beneficios tiene ofrecer conexiones empresariales para sus organizaciones?
Auth0 Universal Login proporciona a los usuarios una experiencia segura, tanto si decide ofrecer inicio de sesión con credenciales de usuario y contraseña como si permite los llamados escenarios traer su propia identidad mediante Social Login. Centralizar la experiencia de inicio de sesión con también aporta beneficios de reconocimiento de marca, incluso si considera que además tendrá requisitos de marca específicos del producto. Los widgets de interfaz de usuario de Auth0 que suelen utilizarse con Universal Login también ofrecen compatibilidad integrada con la internacionalización para usuarios con distintas necesidades de idioma, y la compatibilidad integrada con funciones de Auth0 como MFA y la protección contra ataques le permiten establecer barreras para evitar que los atacantes intenten acceder a las cuentas de los usuarios.Permitir que los usuarios inicien sesión mediante credenciales de usuario y contraseña significa que no depende de que de terceros estén disponibles para que sus usuarios accedan a su sistema. También le permite exigir que las credenciales utilizadas se ajusten a sus políticas corporativas. Auth0 le ayuda con esto al ofrecerle varias opciones para admitir inicios de sesión con usuario y contraseña, y la guía proporcionada le ayudará a comprender cómo puede aprovechar estas opciones. Añadir compatibilidad social en algún momento, como factor primario de autenticación adicional, le ofrece más flexibilidad y puede ayudarle a comprender mejor a sus usuarios sin necesidad de hacerles más preguntas, aprovechando la información ya almacenada por los distintos proveedores de inicio de sesión social.Si tiene un almacén de identidades heredado, también le convendrá consultar Migración de usuarios. Esta sección analiza las ventajas de migrar al almacenamiento de identidades administrado por Auth0 en términos de seguridad y protección.Para las aplicaciones orientadas al cliente, Connect (OIDC) es el protocolo estándar del sector que se usa con más frecuencia, y OIDC cuenta con soporte de primera clase en Auth0. Auth0 ofrece soporte para varios enfoques distintos de integración de aplicaciones, por lo que le convendrá consultar la sección sobre integración de aplicaciones para obtener la información que necesita y tomar una decisión fundamentada.Al llamar a una API desde otra API, o en cualquier situación en la que no haya un contexto de usuario autenticado —como una o más tareas cron, generadores de informes o sistemas de integración/entrega continuas—, necesitará una forma de autorizar la aplicación en lugar de un usuario. Este es un proceso de un solo paso en el que la aplicación se autentica (mediante un y un secreto) y luego se autoriza en una sola llamada. Puede obtener más información al respecto en nuestra línea de trabajo de autorización, en autorización de máquina a máquina (m2m).A menudo, las empresas necesitan separar a sus usuarios por organización y, en ocasiones, los usuarios pueden tener acceso a más de una organización. Saber cuál de estos escenarios es relevante para su empresa ayudará a definir cómo determinar en qué conexión existe un usuario: si necesita hacerlo, cuándo necesita hacerlo y cómo lograrlo. Consulte Home Realm Discovery para determinar si esto es relevante para su empresa.
¿Tiene o tendrá más de una aplicación en su sistema? Si la respuesta es sí, le conviene contar con una experiencia de inicio de sesión centralizada. Para lograr una experiencia fluida de (SSO) entre varias aplicaciones, es fundamental contar con un punto centralizado al que redirigir a sus usuarios para autenticarse. Esto le permite ofrecerles una experiencia coherente si en el futuro agrega autenticación social, incorpora aplicaciones de terceros a su sistema o añade autenticación multifactor como opción (o requisito), y también aprovechar nuevas funcionalidades para mejorar la experiencia de sus usuarios con poco o ningún esfuerzo adicional de desarrollo.
Si tiene más de una aplicación, la práctica recomendada es redirigir a una ubicación centralizada para autenticar al usuario. Con Auth0, esto significa aprovechar Universal Login, que ofrece numerosas ventajas de seguridad y experiencia de usuario listas para usar, entre ellas SSO.
Con Universal Login de Auth0, autenticar usuarios es un proceso breve y sencillo que puede completarse en tres pasos fáciles (todos nuestros Quickstarts lo demuestran y nuestros SDK también ocultan la complejidad):
La detección del dominio de origen (HRD) es el proceso de identificar a qué Proveedor de identidad (o a qué conexión en Auth0) pertenece el usuario antes de autenticarlo. La HRD puede producirse de dos maneras:
Proporcionar un mecanismo para que la decisión se tome en la aplicación
Hacer que Home Realm Discovery se produzca en la página de Universal Login
Es posible que su sistema necesite usar uno o ambos métodos, por lo que es importante comprender todos los enfoques de la HRD para poder aplicar el que mejor se adapte a sus aplicaciones.
Una forma habitual de determinar a qué realm pertenece un usuario es cuando una aplicación está personalizada para cada organización. Como parte de esto, una organización normalmente tendrá su propia instancia de la aplicación, a la que por lo general se accede mediante una URL distinta. Esta copia o instancia puede estar aislada físicamente (ejecutándose en un conjunto independiente de servidores) o virtualmente (ejecutándose en servidores compartidos) y, por lo general, se identifica mediante un nombre de host personalizado (companyA.application1.yourcompany.com) o una ruta (application1.yourcompany.com/companyA).
Si su aplicación ya conoce la conexión específica (IdP) necesaria, también puede enviarla al redirigir al usuario a /authorize, mediante el parámetro de consulta connection.
Si este es el caso de su aplicación o aplicaciones, entonces Home Realm Discovery se reduce simplemente a almacenar org_id en la configuración específica de la aplicación para la organización y enviarlo como parámetro de organización al redirigir al usuario a Universal Login. Hacerlo limitará al usuario a esa organización concreta y a su conjunto de conexiones configuradas.
Si una organización necesita más de un IdP, es posible que tenga que realizar una segunda ronda de Home Realm Discovery (una vez identificada la organización). Auth0 normalmente gestionará esto por usted si está usando la funcionalidad de Organizaciones.
Si el usuario se comparte entre varias organizaciones usando una sola identidad, debe admitir Home Realm Discovery en la página de Universal Login. Esto permitirá que Universal Login identifique primero al usuario y luego presente los realms adecuados para ese usuario, lo que ofrece una mejor experiencia de usuario.Puede enviar los parámetros organization y/o connection agregándolos como parámetros de consulta cuando redirija al usuario al endpoint /authorize. Para obtener más información, consulte la documentación de Authentication API. Sin embargo, por lo general, esto se logra mediante el SDK del lenguaje en el que esté escrita su aplicación.
Hay tres enfoques principales para Home Realm Discovery:
Descubrir el realm a partir del subdominio del correo electrónico del usuario.
Descubrir el realm consultando un identificador de usuario en algún tipo de mapa que relacione identificadores con realms.
Permitir que el usuario elija o introduzca su realm (u organización).
En los dos primeros enfoques, puede plantearse usar “Identifier First Login”. Esto significa que primero solo muestra la opción de introducir un identificador. A continuación, recopila el identificador del usuario y, en función de ese identificador, redirige automáticamente al usuario o le muestra una forma de introducir su contraseña si la redirección no es necesaria. Auth0 proporciona una implementación lista para usar para encargarse de todo esto mediante Universal Login.
Aunque es posible implementar Identifier First Login o permitir que un usuario seleccione su organización en la aplicación en lugar de hacerlo en la página de Universal Login, esto puede añadir complejidad en relación con el inicio de sesión único (SSO), así como la complejidad asociada a replicar ese comportamiento en todas sus aplicaciones. En su lugar, Auth0 recomienda implementar algún tipo de HRD a través de Universal Login.
HRD a través de Universal Login usando el subdominio del correo electrónico
La forma más sencilla de implementar el descubrimiento del dominio de origen en la página de Universal Login es usar el subdominio del correo electrónico del identificador del usuario para asignarlo a su Proveedor de identidad. Esto, por supuesto, solo funciona en situaciones en las que el subdominio del correo electrónico tenga una correspondencia 1:1 con una organización o, al menos, con un Proveedor de identidad.El widget Lock de Auth0 o Universal Login pueden hacerlo por usted si está usando el mapa de dominios en una conexión empresarial; sin embargo, si quiere implementarlo usted mismo, puede hacerlo, pero tendrá que crear una asignación entre el subdominio del correo electrónico y la conexión.Además, al usar la experiencia de Universal Login, la función Organizaciones le ayudará de dos formas:
Si no ha pasado un org_id a /authorize al iniciar la solicitud de inicio de sesión, Auth0 le mostrará al usuario una pantalla para que introduzca la organización a la que pertenece.
Si la Organización tiene más de un IdP asociado, Auth0 le mostrará al usuario botones para elegir la organización o un formulario para introducir un nombre de usuario y una contraseña.
HRD a través de Universal Login mediante el mapa de identificadores a realms
Una segunda alternativa, más compleja, consiste en almacenar un mapa de identificadores a IdP y proporcionar un endpoint público para acceder a esa información. Luego, en la página de Universal Login, puede localizar la conexión y redirigir de nuevo a /authorize con esa conexión. Las principales desventajas de este enfoque son la latencia y, lo que es más importante, la seguridad en lo que respecta al descubrimiento de identificadores: si usa direcciones de correo electrónico, esto facilita mucho que alguien descubra si una dirección de correo electrónico determinada pertenece a uno de sus usuarios.
Cualquier endpoint público debe tener límites de tasa para evitar que los atacantes lo utilicen para descubrir información y para prevenir ataques de denegación de servicio.
HRD mediante Universal Login con elección del usuario
La otra opción es permitir que sus usuarios elijan entre una lista, si no le importa hacer pública la lista de organizaciones que usan su producto, o que el usuario introduzca explícitamente el nombre de su organización. Normalmente, esto se haría antes de redirigir al usuario a Universal Login. Una vez que el usuario le indique a qué organización pertenece, puede redirigirlo a Auth0 con la conexión correspondiente a esa organización especificada, o hacer que Auth0 simplemente le solicite su username y contraseña si se trata de una conexión de base de datos.
Casi todas las aplicaciones B2C ofrecen a sus clientes la posibilidad de crear un nuevo conjunto de credenciales. Esta es una forma de autenticación común con la que todos los usuarios están familiarizados.En Auth0, la autenticación con username y contraseña se presenta de varias formas. Si su aplicación es un proyecto nuevo sin una base de usuarios existente, una conexión de base de datos de Auth0 lista para usar le proporcionará todo lo necesario para empezar a autenticar a sus usuarios. Sin embargo, si tiene un almacén de usuarios heredado (como su propia base de datos de usuarios o un sistema LDAP existente), dispone de un par de opciones para migrar a sus usuarios, como se explica en nuestra guía sobre la migración de usuarios.Independientemente de cómo aprovisione a los usuarios para su conexión de base de datos, la autenticación de esos usuarios es bastante similar. Requiere presentar a los usuarios un formulario para que introduzcan su username y contraseña. Como se menciona en la guía sobre Universal Login, la forma más sencilla y segura de autenticar a los usuarios con username y contraseña es redirigirlos a una página de inicio de sesión centralizada y recopilar allí esas credenciales. Esto permite a Auth0 determinar si ya se han autenticado y omitir por completo el formulario de inicio de sesión cuando no sea necesario.
Recopilar credenciales únicamente en la página de inicio de sesión centralizada reducirá la superficie de exposición ante posibles filtraciones de secretos de los usuarios. También reducirá la necesidad de recopilar credenciales innecesariamente. Consulte Universal Login para obtener más información.
Una vez que haya definido cómo quiere autenticar a sus usuarios, el siguiente paso es determinar cómo iniciará esa autenticación. Normalmente, cada aplicación tendrá su propio punto de partida.
Las aplicaciones móviles nativas (y las aplicaciones de escritorio) deben usar el navegador del sistema para la autenticación; de lo contrario, quedan expuestas a riesgos de seguridad adicionales. Consulte Native Login para obtener más información.
Como ya se ha explicado, hemos observado que la mayoría de nuestros clientes usan OpenID Connect (OIDC) como protocolo estándar del sector para sus aplicaciones orientadas al cliente. Determinar qué flujo de OIDC usar es su primera tarea, y le conviene empezar por revisar nuestra guía de asignación de concesiones.Si quiere permitir que usuarios anónimos accedan a alguna parte de su aplicación, debe determinar si los redirigirá de inmediato o si solo les pedirá que redirijan cuando sea necesario (o quizá una combinación de ambas opciones; consulte Redirect Users After Login para obtener más información). Si los usuarios pueden usar deep link a una versión protegida (o un área protegida) de su sitio, deberá determinar qué enlaces de su aplicación provocarán una redirección automática a Auth0.
Es importante tener en cuenta la experiencia del usuario cuando alguien llega por primera vez a su aplicación. Si su aplicación admite acceso de usuario anónimo (algo bastante común en las aplicaciones de comercio electrónico), hay distintos escenarios que debe considerar:
Si vuelve a la aplicación después de haber iniciado sesión anteriormente, o
Si es la primera vez que accede a la aplicación:
Si ya ha accedido a otra aplicación que usa el mismo inquilino de Auth0,
Si alguna vez se ha autenticado en este dispositivo o navegador (o quizá no lo ha hecho desde hace mucho tiempo).
Cuando un usuario anónimo accede a su aplicación, a menudo puede ser conveniente que la aplicación detecte si el usuario ya inició sesión en otra aplicación de la misma familia, o que recuerde a este usuario incluso si la aplicación es una SPA sin estado. Por ejemplo, si puede determinar que el usuario ya inició sesión, podría decidir que el encabezado de la interfaz de usuario de la aplicación no muestre un botón de inicio de sesión y que, en su lugar, presente un menú de cuenta o perfil para el usuario. Para lograrlo, le convendrá utilizar la “autenticación silenciosa”. La autenticación silenciosa le permitirá comprobar si el usuario ha iniciado sesión sin pedirle que inicie sesión si no lo ha hecho. Luego, la aplicación puede mostrar un botón de inicio de sesión si es necesario. Sin embargo, si el usuario ya inició sesión, recibirá tokens y no tendrá que volver a mostrarle un botón de inicio de sesión.
Comprobar si existe una sesión iniciada redirigiendo a Auth0 puede ser útil para su aplicación, pero si esto va a generar muchas solicitudes, debe implementar un mecanismo de limitación para evitar latencia o la aplicación de límites de tasa.Las llamadas a la Management API están sujetas a la política de límites de tasa de Auth0. Debe tener esto en cuenta y, para ayudarle, Auth0 generalmente recomienda usar el SDK de Auth0 adecuado para su entorno de desarrollo en lugar de llamar directamente a nuestras API.
Hay diversos motivos por los que alguien podría enlazar directamente a una página concreta dentro de tu aplicación a la que solo pueden acceder los usuarios autenticados. Si esto es posible en tu aplicación, debes redirigir automáticamente al usuario a Auth0 si no está autenticado. Una vez que se autentique y el lo devuelva a tu aplicación, puedes redirigirlo al lugar al que quería ir en primer lugar.
La mayoría de los frameworks de autenticación modernos admiten middleware para redirigir a un Servidor de autorización como Auth0. Al seleccionar uno, tenga en cuenta lo siguiente:
Compatibilidad con clientes confidenciales, clientes no confidenciales o ambos
Compatibilidad con la configuración mediante el endpoint de descubrimiento o definida explícitamente en línea
Compatibilidad con la validación de tokens, incluidas la expiración, las firmas, los claims y los alcances
La autenticación es el proceso de verificar la identidad del usuario. El resultado de la autenticación en un contexto de OIDC es un . Este token contiene información sobre el usuario y solo debería poder obtenerse si el usuario se autentica mediante uno o más factores, según lo definido por el servidor de autorización (la forma más común es identificador de usuario y contraseña). Hay algunos aspectos que quizá debas considerar además de obtener un ID Token:
¿También necesitamos un Token de acceso para llamar a una API compartida?
Antes de pasar a producción, debes asegurarte de que solo estén habilitados, para cada aplicación, los grants que estés usando en la configuración de la aplicación.
Si su SDK solo admite el grant de código de autorización, o si necesita un Token de acceso o un , el grant de código de autorización (con o sin PKCE) también puede usarse para obtener un ID Token. El grant de código de autorización incluye una llamada adicional a la API para intercambiar el code por un token, lo que puede generar una latencia adicional innecesaria si lo único que necesita es el ID Token. En muchos casos, el flujo híbrido se implementa para proporcionar un acceso óptimo al ID Token y, al mismo tiempo, aprovechar el flujo de trabajo del grant de código de autorización para obtener de forma segura Tokens de acceso y Tokens de actualización.
Aunque Auth0 admite el uso del grant implícito para aplicaciones basadas en navegador que solo requieren un ID Token, se recomienda usar el grant de código de autorización con PKCE. Para obtener información detallada, consulte OAuth2 Implicit Grant and SPA en el blog de Auth0.Si necesita un Token de actualización para poder obtener un nuevo Token de acceso o ID Token sin tener que volver a autenticar al usuario, debe usar el grant de código de autorización.
Los sistemas de autenticación son importantes porque evitan que accedan a aplicaciones y datos de usuario a los que no deberían tener acceso. Queremos colocar tantas barreras como sea posible entre esos actores maliciosos y el acceso a nuestros sistemas. Una de las formas más sencillas de hacerlo es asegurarse de que su protección contra ataques con Auth0 esté configurada correctamente, así que dedique un momento a leer la guía sobre este tema y a comprobar que funciona correctamente en su caso.
Auth0 gestiona la detección de anomalías de forma transparente y ofrece una excelente función de seguridad para su producto. Si va a utilizarla, asegúrese de haber configurado su proveedor de correo electrónico y sus plantillas de correo electrónico antes de activar el envío de correos electrónicos a sus usuarios.
En una reestructuración a gran escala, no siempre es posible —o práctico— actualizar todas sus aplicaciones a la vez. De hecho, nuestra práctica recomendada es planificar un enfoque iterativo a la hora de integrar con Auth0. Si sus aplicaciones ya participan en el inicio de sesión único (SSO) y su sistema de identidad heredado admite protocolos como OIDC o , tiene un par de opciones si quiere seguir ofreciendo SSO mientras integra con Auth0:
Actualice su proveedor de identidad existente en su sistema de SSO heredado para que redirija a Auth0 para iniciar sesión (por ejemplo, mediante SAML), o
Configure Auth0 para que redirija a su sistema de SSO heredado para iniciar sesión. Esto requiere configurar su sistema heredado como un Proveedor de identidad (IdP) en Auth0 (es decir, ya sea mediante SAML o OIDC).
Ofrecer una experiencia de SSO con su sistema heredado puede añadir complejidad, pero puede valer la pena para ofrecer una experiencia de usuario más fluida mientras integra con Auth0. Si piensa seguir este enfoque, planificarlo desde el principio puede ayudar a garantizar que sea posible. Si todavía no tiene SSO en un servicio centralizado, es poco probable que la complejidad de añadirlo compense los beneficios.
Este es un tema complejo que probablemente requerirá un análisis adicional según su arquitectura heredada actual, y le recomendamos que solo lo evalúe si actualmente tiene compatibilidad con SSO en su sistema heredado. Nota: si actualmente redirige desde sus aplicaciones a un sistema centralizado para autenticar a sus usuarios y ese sistema solo solicita credenciales si aún no tiene una sesión con el sistema centralizado, entonces tiene una implementación de SSO heredada.
El modelo de “traiga su propia identidad” se ha convertido en un requisito imprescindible para casi todas las aplicaciones B2B. La mayoría de las empresas esperan poder integrar su IdP en su aplicación para que sus empleados no tengan que guardar otro juego de credenciales. Esta es una forma muy valiosa de simplificar la experiencia de autenticación del usuario sin comprometer la seguridad, y usar Universal Login facilita empezar a añadir compatibilidad con conexiones empresariales con un impacto mínimo.
Una vez que empiece a admitir conexiones empresariales para los usuarios, debe implementar algún tipo de Home Realm Discovery para poder determinar a qué conexión enviar al usuario para la autenticación.
Con la compatibilidad con conexiones empresariales, las identidades y credenciales de los usuarios son administradas por el proveedor de identidad de la organización de sus clientes, junto con determinados atributos de identidad, que Auth0 usará para completar el perfil del usuario.
“Traiga su propia identidad” es una excelente funcionalidad, pero si no la ofrece desde el primer día, y a veces incluso si lo hace, puede que una organización quiera cambiar a su propio IdP después de haber usado la aplicación durante un tiempo. Necesitará una forma de vincular cuentas de usuario para proporcionar una manera eficaz de asociar la nueva identidad con la identidad existente en la base de datos.
En una época en la que el uso indebido de las credenciales de usuario alcanza niveles sin precedentes, proteger sus sistemas supone un reto, especialmente cuando es tan habitual que los atacantes roben la información de identidad de los usuarios. Sin embargo, una de las formas más eficaces de hacerlo es ofrecer a los usuarios la posibilidad de configurar un segundo factor para proteger su cuenta, lo que se conoce más comúnmente como autenticación multifactor. Esto garantiza que solo un usuario legítimo pueda acceder a su cuenta, incluso si utiliza un nombre de usuario y una contraseña que se hayan visto comprometidos en otra aplicación.
Es bastante habitual que las aplicaciones orientadas al cliente ofrezcan a los usuarios la opción de añadir un segundo factor en lugar de obligarlos a usarlo. Para obtener más información al respecto, consulte cómo ofrecer a sus usuarios la opción de añadir MFA.
Auth0 admite varias opciones para habilitar MFA y proteger el acceso a las cuentas de usuario, y existen varias prácticas que ayudan a garantizar que realmente ofrezca una barrera de segundo factor flexible:
Auth0 Guardian: un servicio que proporciona tanto la generación de notificaciones Push como una aplicación para aprobar o denegar solicitudes. Push envía una notificación al dispositivo previamente registrado del usuario —normalmente un móvil o una tableta—, desde el que este puede aprobar o denegar de inmediato el acceso a la cuenta con solo pulsar un botón.
Contraseña de un solo uso basada en tiempo (TOTP): le permite registrar un dispositivo —como Google Authenticator— que genera una contraseña de un solo uso que cambia con el tiempo y que puede introducirse como segundo factor para validar la cuenta de un usuario.
SMS: para enviar un código de un solo uso por SMS que luego se pide al usuario que introduzca antes de poder completar la autenticación.
Voz: para entregar un código de un solo uso mediante una llamada telefónica que luego se pide al usuario que introduzca antes de poder completar la autenticación.
Duo: le permite usar su cuenta de Duo para la autenticación multifactor.
Correo electrónico: le permite usar su cuenta de correo electrónico para la autenticación multifactor.
Aunque el flujo de trabajo de MFA que utiliza tecnologías como Guardian o Google Authenticator suele proporcionarse a través de una aplicación independiente que se ejecuta en un dispositivo móvil o una tableta, si no quiere que sus clientes tengan que descargar una aplicación aparte, Auth0 también le proporciona un SDK que puede usar para crear el flujo de trabajo del segundo factor directamente en sus aplicaciones móviles existentes.
Ofrecemos una guía de planificación en formato PDF que puede descargar y consultar para conocer en detalle nuestras estrategias recomendadas.Guía de planificación del proyecto de B2B IAM
Arquitectura de múltiples organizaciones (multitenencia)
Muchas plataformas B2B implementan algún tipo de aislamiento y/o marca para las organizaciones de sus clientes, y esto puede añadir complejidad a cualquier sistema de gestión de identidades y accesos (IAM). Si este es su caso, le recomendamos que dedique algo de tiempo a revisar nuestras directrices y prácticas recomendadas para este tipo de entorno.Arquitectura de múltiples organizaciones
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma