La forma en que configures la arquitectura de tu Tenant de Auth0 afecta a tu implementación de IAM B2B.
Comprender tu aplicación es clave para entender cómo puede aprovecharse Auth0 para satisfacer tus necesidades. Según nuestra experiencia, los clientes que obtienen más éxito empiezan con una visualización de la arquitectura propuesta —o, en muchos casos, ya existente— y la utilizan como referencia a medida que avanzan. También es importante entender cómo encaja tu aplicación en tu organización; las Cuentas e inquilinos de Auth0 son la base para agrupar y estructurar los recursos de Auth0, y puede que necesites aprovechar un despliegue existente de Auth0 para integrarte con Single Sign-On (SSO), la gestión de perfiles centralizada de usuarios, la facturación consolidada o funcionalidades similares.
Si tienes varias aplicaciones y necesitas aprovechar SSO, te recomendamos revisar nuestro material de formación How to Implement Single Sign-On antes de continuar.
Hemos comprobado que invertir tiempo por adelantado en definir el panorama de la arquitectura da resultados a largo plazo, y hay varios aspectos que querrás tener en cuenta al analizar la funcionalidad y el flujo de trabajo:
¿Qué aspecto debe tener la URL cuando Auth0 necesite mostrar una página web a un usuario?
¿Cómo se puede estructurar Auth0 para dar soporte a tu SDLC (ciclo de vida del desarrollo de software)?
¿Cómo puedes asegurarte de que tus Tenants de Auth0 estén correctamente asociados a tu contrato?
¿Qué debes tener en cuenta si hay otros proyectos en tu organización que se integran con Auth0? En particular, proyectos dirigidos a su propio dominio de usuarios o a uno distinto (por ejemplo, aplicaciones que solo utilizarán los empleados).
¿Cómo puedes alinear la estructura y el dominio de la organización de tus clientes con tu despliegue de Auth0?
Las organizaciones suelen dar servicio a más de un dominio de usuario —clientes, empleados y afiliados son los más habituales—, por lo general con poca o ninguna superposición: los empleados, por ejemplo, no usan las mismas aplicaciones que los clientes, y viceversa. En algunos casos, también puede ser necesario segmentar aún más dentro de un dominio: por ejemplo, grupos separados de clientes que usan productos distintos y no conectados entre sí. Auth0 ofrece una forma de segregar a tus usuarios y los recursos asociados, y el aprovisionamiento de Tenants trata este tema con más detalle. Si necesitas aprovisionar un Tenant independiente, también querrás asociarlo a tu cuenta de Auth0 existente, para poder aprovechar al máximo las ventajas del nivel de suscripción contratado por tu organización.
No es raro que las empresas tengan requisitos de identidad para múltiples comunidades de usuarios: clientes, socios, empleados, etc. Por eso, asegúrate de tener en cuenta otros proyectos o requisitos futuros al diseñar tu arquitectura.
Además, sin duda contarás con un conjunto ya establecido de procesos y procedimientos como parte de tu ciclo de vida del desarrollo de software (SDLC). Por lo tanto, también querrás consultar nuestra guía de soporte para SDLC sobre el aprovisionamiento de Tenants de Auth0 para dar soporte a ese proceso.Para las aplicaciones orientadas al cliente, normalmente vemos que OpenID Connect (OIDC) es el protocolo más utilizado. OIDC utiliza flujos basados en la web con URL del navegador que se presentan al usuario. De forma predeterminada, las URL orientadas al cliente como parte del soporte OIDC de Auth0 llevan la marca de Auth0; sin embargo, recomendamos usar la funcionalidad de dominio personalizado de Auth0 para ofrecer una identidad corporativa coherente y abordar también posibles dudas de confianza por parte del usuario antes de que surjan.
Es posible que otros grupos dentro de tu organización también estén trabajando con Auth0; no es raro que nuestros clientes tengan departamentos distintos que atienden a diferentes comunidades de usuarios. Identificarlos puede influir en tus decisiones de diseño, y hacerlo con antelación podría evitar decisiones que más adelante resulten costosas.
Si algunas o todas las organizaciones de tus clientes necesitan su propia URL personalizada, o si usan proveedores sociales que requieren una página de consentimiento personalizada con la marca de la organización, te recomendamos crear Tenants de Auth0 independientes para esas organizaciones; consulta Aprovisionamiento de Tenants para organizaciones complejas para obtener más información.
Todo comienza con un Tenant de Auth0. Aquí configurará su uso de Auth0 y es donde se definen, administran y almacenan los recursos de Auth0, como las Aplicaciones, las Conexiones y los perfiles de usuario. Se accede a un Tenant de Auth0 a través del Dashboard de Auth0, y desde el Dashboard también puede crear Tenants adicionales asociados; puede crear más de un Tenant de Auth0 para estructurarlos de forma que aíslen distintos dominios de usuarios y, al mismo tiempo, den soporte a su ciclo de vida del desarrollo de software (SDLC).
Los nombres de los Tenants no se pueden cambiar ni reutilizar una vez eliminados. Por lo tanto, asegúrese de estar conforme con los nombres antes de crear sus Tenants de Auth0.
Determinar el nivel de aislamiento que necesita para sus dominios de usuarios es un paso importante y, junto con sus requisitos de marca, le ayudará posteriormente a determinar cuántos Tenants de Auth0 necesitará en su entorno de producción. Dado que recomendamos crear un conjunto completo de Tenants de soporte para SDLC por cada Tenant de Auth0 que ejecute en un entorno de producción, la cantidad de Tenants de Auth0 que deberá administrar puede aumentar rápidamente. Por lo tanto, antes de crear varios Tenants de Auth0 para producción, debe evaluarlo cuidadosamente y consultar nuestra guía sobre marca antes de tomar una decisión final.
Aprovisionamiento de Tenants para organizaciones complejas
En la mayoría de los casos, no es necesario aprovisionar Tenants de Auth0 independientes para las organizaciones de sus clientes. Esto se ha vuelto aún más fácil con el lanzamiento de nuestra nueva funcionalidad Organizations. Sin embargo, en determinadas circunstancias, puede resultar útil para reducir la complejidad de su configuración. Por ejemplo, recomendamos aprovisionar un Tenant de Auth0 independiente para la organización de cada cliente como práctica recomendada si:
Las organizaciones de sus clientes necesitan una URL de inicio de sesión personalizada y exclusiva para la organización. Por lo general, esto solo ocurre si permite que sus organizaciones tengan su propia URL personalizada en lugar de usar una URL de inicio de sesión común. Auth0 admite un por Tenant.
Las organizaciones de sus clientes usan proveedores sociales para iniciar sesión. En este caso, suele ser conveniente que la organización tenga una página de consentimiento personalizada para el proveedor social con su propia imagen de marca.
Si se da cualquiera de estas situaciones, recomendamos crear un Tenant de Auth0 independiente para cada organización que cumpla alguno de los criterios anteriores.
Mantener varios Tenants de Auth0 puede añadir complejidad a su sistema y no debe hacerse a menos que sea absolutamente necesario.
Para garantizar que sus Tenants estén todos asociados a su acuerdo contractual con Auth0 y tengan las mismas funciones, asegúrese de que todos sus Tenants estén asociados a la cuenta de su empresa. Si tiene desarrolladores individuales que quieren crear sus propios entornos aislados para realizar pruebas, asegúrese de que también estén asociados a su cuenta para que tengan los mismos permisos. Para ello, debe ponerse en contacto con su representante de Auth0 o con el Centro de soporte de Auth0.
Cuando configuras tu Tenant de Auth0, la URL para acceder a ese Tenant tendrá el formato https://{yourTenant}.auth0.com. Proporcionar un dominio personalizado (también conocido como URL de vanidad) para tu Tenant de Auth0 no solo es un factor importante para satisfacer tus requisitos de marca, sino que, aún más importante, también te aportará ventajas de seguridad:
Es más difícil suplantar tu dominio mediante phishing si tienes una URL de vanidad, ya que quien intenta hacerlo también tendría que crear una URL de vanidad para imitar la tuya. Por ejemplo, con un dominio personalizado puedes usar tu propio certificado para obtener una “validación extendida”, lo que dificulta aún más el phishing.
Solo se permite un dominio personalizado por Tenant de Auth0. Esto se debe a que un Tenant en Auth0 está pensado para representar un “dominio” de usuarios. Si necesitas más de una URL de vanidad, probablemente tengas más de un dominio de usuarios y deberías usar varios Tenants.
El nombre de tu dominio personalizado también debe transmitir al usuario la confianza de que este es el lugar adecuado para introducir sus credenciales, y te recomendamos crear tu dominio personalizado en todos los entornos desde el principio para asegurarte de que las pruebas sean coherentes entre entornos. ¡Es extremadamente importante enseñar a tus usuarios a identificar URLs sospechosas al introducir sus credenciales!
Crea un dominio personalizado (también conocido como CNAME) para tu Tenant de Auth0, y crea también uno en desarrollo para asegurarte de que has configurado correctamente el CNAME. Por ejemplo, podrías crear un CNAME que asigne login.mycompany.com a mycompany-prod.auth0.com.
En casi todos los casos, los clientes han tenido más éxito al adoptar una estrategia de dominio centralizado para la autenticación en múltiples marcas de productos o servicios. Esta estrategia proporciona a los usuarios una experiencia coherente y también reduce la complejidad de implementar y mantener varios Tenants de Auth0 en un entorno de producción. Si estás considerando tener múltiples dominios para distintas marcas, consulta la guía de marca antes de empezar a implementar.
Todas las empresas tienen alguna forma de ciclo de vida del desarrollo de software (SDLC) y, a lo largo del proceso de desarrollo, querrá alinearse con esa estrategia. Por ejemplo, necesita poder probar su integración con Auth0 de forma similar a como prueba las propias aplicaciones. Por lo tanto, es importante estructurar los Tenants de Auth0 para respaldar su SDLC, y existe un patrón uniforme que nuestros clientes suelen seguir en cuanto a las prácticas recomendadas relacionadas con la distribución de los Tenants para hacerlo:
Entorno
Nombre de ejemplo del Tenant
Descripción
Desarrollo
company-dev
Un entorno compartido donde se realiza la mayor parte del trabajo de desarrollo
QA/Pruebas
company-qa o company-uat
Un entorno para realizar pruebas formales de los cambios que ha realizado
Producción
company-prod
El Tenant de producción
En algunos casos, también puede que quiera crear uno o más entornos sandbox (por ejemplo, company-sandbox1, company-sandbox2) para poder probar cambios sin comprometer su entorno de desarrollo. Este puede ser el lugar donde pruebe scripts de implementación y similares.
También puede aprovechar nuestras listas de comprobación de implementación, que puede descargar y personalizar para adaptarlas a las necesidades de su proyecto de implementación.
Los clientes con una suscripción Enterprise deben asegurarse de que los Tenants configurados para respaldar su SDLC estén correctamente vinculados a su suscripción. Esto garantizará que cada Tenant tenga habilitado un conjunto uniforme de funcionalidades.
Ofrecemos una guía de planificación en formato PDF que puede descargar y consultar para obtener más información sobre las estrategias que recomendamos.Guía de planificación de proyectos de IAM B2B
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 nuestra guía y las recomendaciones de buenas prácticas para este tipo de entorno.Arquitectura de múltiples organizaciones
Autenticar
Administrar usuarios
Personalizar
Auth0 AI
Plataforma