Saltar al contenido principal

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

Tu plan de Auth0 o tu acuerdo personalizado determinan si esta característica está disponible. Para obtener más información, consulta Precios.
Usa una conexión de base de datos personalizada cuando quieras proporcionar acceso a tu propio almacén de datos de identidad independiente (heredado) para los siguientes fines:
  • Autenticación: Usa tu base de datos como en Auth0 para autenticar usuarios. (Esto se conoce como autenticación heredada).
  • Importar usuarios: Usa la migración automática (migración gradual o diferida)
  • Acceso mediante proxy a un inquilino de Auth0: Usa la arquitectura multiinquilino de Auth0.
Puedes crear y configurar una conexión de base de datos personalizada de una de las siguientes maneras:
  1. Usa el endpoint Create connections con la estrategia auth0.
  2. Ve a Auth0 Dashboard > Authentication > Database, crea la conexión y habilita la opción Use my own database para permitir la edición del script de Action de base de datos.
    Habilitar la opción Use My Own Database para base de datos personalizada

​
Cómo funciona

Como se muestra en el siguiente diagrama, utiliza conexiones de base de datos personalizadas como parte del flujo de para obtener la información de identidad del usuario desde su propio almacén de identidades heredado.
Anatomía de las conexiones de base de datos personalizadas
Además de los elementos comunes a todos los tipos de conexión de base de datos, una conexión de base de datos personalizada le permite configurar scripts de Action: código personalizado que se utiliza al interactuar con su almacén de identidades heredado. Auth0 proporciona plantillas de scripts de Action para bases de datos personalizadas para su configuración, y las que utilice dependerán de si está creando una conexión de base de datos personalizada para autenticación heredada o para migración automática.

Práctica recomendada

Los scripts de Action pueden implementarse como funciones anónimas; sin embargo, esto dificulta la depuración cuando se debe interpretar la pila de llamadas generada como resultado de una condición de error excepcional. Por comodidad, recomendamos asignar un nombre de función a cada script de Action.

​
Escenario de autenticación heredada

En un escenario de autenticación heredada, se crea un nuevo registro de usuario en Auth0 durante el primer inicio de sesión del usuario, pero Auth0 no almacena el hash de la contraseña del usuario. Auth0 siempre usará el almacén de identidades heredado y la identidad que contiene para autenticar al usuario.
Las conexiones de base de datos personalizadas también se usan fuera del flujo de Universal Login. Por ejemplo, se invoca el script de Action changePassword de una conexión cuando se realiza una operación de cambio de contraseña para un usuario que reside en un almacén de identidades heredado.

​
Escenario de migración automática

Durante la migración automática o gradual, Auth0 crea un nuevo usuario en un almacén de identidades (base de datos) administrado por Auth0. A partir de ese momento, Auth0 siempre utiliza la identidad del almacén de identidades administrado por Auth0 para autenticar al usuario. Para que esto ocurra, primero Auth0 requiere que el usuario se autentique en el almacén de identidades heredado, y solo si esto se realiza correctamente se creará el nuevo usuario. El nuevo usuario se creará con el mismo id y la misma contraseña que se proporcionaron durante la autenticación.

Práctica recomendada

La creación de un usuario en un escenario de migración automática normalmente ocurre después de que finalice el script de Action login. Por lo tanto, recomendamos que no intente eliminar ningún usuario de un almacén de identidades heredado como una operación en línea (es decir, dentro del script login), sino que realice la eliminación como un proceso independiente. Esto evitará la eliminación accidental de un usuario si se produce un error durante el proceso de migración.
En un escenario de migración automática, los usuarios permanecen en el almacén de identidades heredado y pueden eliminarse o archivarse si es necesario. Un efecto secundario de esto puede producirse si un usuario se elimina de Auth0, pero sigue presente en el almacén de identidades heredado. En este caso, un Login iniciado por el usuario eliminado podría dar lugar a que se ejecute el script login y/o getUser, y a que el usuario se vuelva a migrar desde el almacén de identidades heredado.

Práctica recomendada

Recomendamos marcar cualquier identidad de usuario heredada como migrada antes de que finalice login o getUser, y antes de cualquier eliminación posterior del almacén heredado.

​
Tamaño

El tamaño total de la implementación de cualquier script de Action no debe superar los 100 kB. Cuanto mayor sea el tamaño, mayor será la latencia introducida por el proceso de empaquetado y transporte que utiliza la plataforma Webtask serverless de Auth0, lo que afectará al rendimiento de su sistema.
El límite de 100 kB no incluye ningún módulo de npm al que se haga referencia en una instrucción require.

​
Entorno

Los scripts de Action se ejecutan como una serie de funciones de JavaScript invocadas en una instancia de un contenedor Webtask sin servidor. En este contexto, se proporciona un entorno específico, junto con una serie de artefactos suministrados tanto por el contenedor Webtask como por el de Auth0 (su inquilino de Auth0).

​
módulos de npm

Los contenedores Webtask serverless de Auth0 pueden usar una amplia variedad de módulos de npm; los módulos de npm no solo reducen el tamaño general del código del script de Action, sino que también proporcionan acceso a una amplia variedad de funcionalidades predefinidas. Muchos módulos de npm disponibles públicamente son compatibles de forma predeterminada. La lista se ha compilado y revisado para detectar posibles problemas de seguridad. Si necesita un módulo de npm que no sea compatible de forma predeterminada, puede enviar una solicitud a través del portal de soporte de Auth0 o de su representante de Auth0. Auth0 evaluará su solicitud para determinar si es adecuada. Actualmente, Auth0 no admite el uso de módulos de npm desde repositorios privados.

​
Variables

Los scripts de Action de Auth0 admiten variables de entorno, a las que se accede mediante el objeto configuration, disponible globalmente. Para obtener más información, consulte la sección Agregar parámetros de configuración en Crear conexiones de base de datos personalizadas.

Práctica recomendada

El objeto configuration debe tratarse como de solo lectura y usarse para almacenar información confidencial, como credenciales o claves de API para acceder a repositorios de identidades externos. Esto evita tener valores sensibles codificados de forma fija en un script de Action.
El objeto configuration también puede usarse para admitir cualquier estrategia de Software Development Life Cycle (SDLC) que utilice, ya que le permite definir variables con valores específicos de cada inquilino. Esto evita valores codificados de forma fija en un script de Action, que pueden cambiar según el inquilino que lo ejecute.

​
objeto global

Los contenedores Webtask sin servidor de Auth0 se aprovisionan a partir de un grupo asociado a cada inquilino de Auth0. Cada instancia de contenedor pone a disposición el objeto global, al que se puede acceder desde todos los scripts de Action que se ejecutan dentro de esa instancia. El objeto global actúa como una variable global exclusiva del contenedor y puede usarse para definir información o funciones que se utilicen en todos los scripts de Action que se ejecutan en la instancia del contenedor. Esto significa que el objeto global puede usarse para almacenar en caché recursos costosos, siempre que esos recursos no sean específicos de un usuario. Por ejemplo, podría usarlo para almacenar un para una API de registros de terceros que proporciona funcionalidad no específica del usuario. O bien podría almacenar un Token de acceso para su propia API no específica del usuario definida en Auth0 y obtenida mediante el flujo de credenciales del cliente.
Un script de Action puede ejecutarse en cualquiera de las instancias de contenedor que ya estén en ejecución o en una instancia de contenedor recién creada (que posteriormente puede añadirse al grupo). No existe afinidad de contenedor para la ejecución de scripts de Action en Auth0. Esto significa que debe evitar almacenar cualquier información específica del usuario en el objeto global y asegurarse siempre de que cualquier declaración realizada dentro del objeto global contemple también la inicialización.
Cada vez que se recicla un contenedor Webtask, o cada vez que se crea una nueva instancia de contenedor Webtask, se restablece el objeto global que define. Por lo tanto, cualquier asignación declarada dentro del objeto global asociado a un contenedor también debe contemplar la inicialización.

Práctica recomendada

Para proporcionar flexibilidad de rendimiento, los contenedores Webtask sin servidor se aprovisionan en Auth0 de forma ad hoc y también están sujetos a varias políticas de reciclaje. En general, recomendamos no asumir que la vida útil de un objeto global sea superior a 20 minutos.

​
Seguridad

​
Acceder al almacenamiento de identidades heredado mediante una API personalizada

Proteger el almacenamiento de identidades heredado frente al acceso indiscriminado es una práctica recomendada. Exponer una base de datos directamente a internet, por ejemplo, puede ser extremadamente problemático: las interfaces de bases de datos SQL y similares ofrecen una funcionalidad excesivamente amplia, lo que vulnera el principio de mínimo privilegio desde el punto de vista de la seguridad.

Práctica recomendada

Recomendamos implementar una API para aplicar el principio de mínimo privilegio a su almacén de identidades heredado (base de datos), en lugar de simplemente habilitar acceso general por internet.
La alternativa es crear una API (personalizada) sencilla, protegida mediante el uso de un token de acceso, a la que pueda llamar cada script de Action. Esta serviría como interfaz para el almacén de identidades heredado. Luego, puede utilizarse el flujo Client Credentials Grant para obtener un token de acceso desde un script y, posteriormente, almacenarlo en caché para reutilizarlo en el objeto global a fin de mejorar el rendimiento. Después, la API puede ofrecer un conjunto acotado de endpoints protegidos que realicen únicamente la funcionalidad de administración heredada necesaria (por ejemplo, read user, change password).

Práctica recomendada

De forma predeterminada, Auth0 le proporcionará un token para cualquier API si se autentica correctamente e incluye la audiencia adecuada. Restringir el acceso a la API del almacén de identidades heredado limitando la asignación de tokens de acceso mediante el uso de una Rule evitará el uso no autorizado y mitigará diversos escenarios de ataque, como aquellos en los que se intercepta la redirección a /authorize y se agrega la audiencia de la API.

​
Permitir acceso al almacén de identidades heredado mediante lista de permitidos

Tanto si administra el acceso a un almacén de identidades heredado mediante una API personalizada como si usa la interfaz nativa proporcionada, restrinja el acceso a la lista de direcciones IP asociadas a su inquilino de Auth0. La inclusión en una lista de permitidos limita el acceso al almacén de identidades heredado y garantiza que solo se permitan los scripts de Action de base de datos personalizados definidos en Auth0.
La lista de direcciones IP permitidas de Auth0 se comparte entre todos los inquilinos de Auth0 definidos en una región. Nunca use la lista de permitidos como único método para proteger el acceso a su almacén de identidades heredado; hacerlo podría generar vulnerabilidades de seguridad y permitir el acceso no autorizado a sus usuarios.

​
Más información