Autenticación (B2C)

Cómo funciona la autenticación en su implementación de IAM B2C.

Para ofrecer 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, username y contraseña, sin contraseña; y, a menudo, se recomienda ir más allá de un primer factor habilitando la autenticación multifactor (MFA).

​

Práctica recomendada

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 sus credenciales los usuarios?
• ¿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 hackers 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 contextos lingüísticos?
• ¿Cómo ofrecerá una buena experiencia de usuario mientras migra desde un sistema de autenticación heredado?
• ¿Qué debe tener en cuenta al integrar aplicaciones con Auth0?
• ¿Pueden los usuarios iniciar sesión con sus cuentas sociales existentes (por ejemplo, Facebook o Google)?
• ¿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 token de acceso de usuario de una API a otra?

Auth0 Universal Login proporciona a los usuarios una experiencia segura, independientemente de si decide ofrecer inicio de sesión con credenciales de ID de usuario/contraseña o permitir los llamados escenarios Bring Your Own Identity mediante Social Login. Centralizar la experiencia de inicio de sesión con Universal Login también aporta ventajas de reconocimiento de marca, incluso si considera que también tendrá requisitos de marca específicos del producto. Los widgets de interfaz de usuario de Auth0 que normalmente se usan con Universal Login también ofrecen compatibilidad inmediata con la internacionalización para usuarios con distintos requisitos de idioma, y la compatibilidad inmediata con funciones de Auth0 como MFA y la protección contra ataques le permite establecer barreras para evitar que los hackers intenten acceder a las cuentas de los usuarios.

Permitir que los usuarios inicien sesión mediante credenciales de ID de usuario/contraseña significa que no depende de terceros proveedores de identidad 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 múltiples opciones para admitir inicios de sesión con ID de usuario/contraseña, y la guía proporcionada le ayudará a entender cómo aprovechar estas opciones. Añadir compatibilidad social en algún momento, como factor de autenticación principal adicional, le aporta más flexibilidad y puede ayudarle a conocer 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 ya dispone de un almacén de identidades heredado, también le convendrá consultar Migración de usuarios. En esta sección se analizan 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, OpenID Connect (OIDC) es el protocolo estándar del sector más utilizado, y Auth0 ofrece soporte nativo para OIDC. Auth0 ofrece varios enfoques distintos para integrar diferentes tipos de aplicaciones, por lo que le convendrá consultar la sección sobre integración de aplicaciones para obtener la información necesaria y tomar una decisión fundamentada.

Al llamar a una API desde otra API, o en cualquier situación en la que no exista el contexto de un usuario autenticado, como uno o varios trabajos 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 ID de cliente y un secreto) y luego se autoriza en una sola llamada. Puede obtener más información al respecto en nuestra sección de autorización, en autorización de máquina a máquina (m2m).

​

Universal Login

¿Tiene o tendrá más de una aplicación en su sistema? Si la respuesta es sí, le convendrá contar con una experiencia de inicio de sesión centralizada. Para lograr una experiencia fluida de inicio de sesión único (SSO) entre varias aplicaciones, es fundamental contar con una ubicación centralizada a la 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 la 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.

​

Práctica recomendada

Si tiene más de una aplicación, la práctica recomendada es redirigir a una ubicación centralizada para autenticar a los usuarios. Con Auth0, esto significa aprovechar Universal Login, que ofrece muchas ventajas de seguridad y experiencia de usuario listas para usar, incluido SSO.

Auth0 Universal Login simplifica la autenticación de usuarios y permite completarla en tres sencillos pasos (todos nuestros Quickstarts lo demuestran y nuestros SDK también abstraen esa complejidad):

1. Determine cómo y cuándo desea redirigir desde su aplicación.
2. Configure la marca adecuada y/o el HTML personalizado en su configuración de Auth0.
3. Configure su aplicación para recibir y gestionar la respuesta del Servidor de autorización.

​

Autenticación con username y contraseña

Casi todas las aplicaciones B2C permiten a sus clientes crear un nuevo conjunto de credenciales. Esta es una forma común de autenticación que resulta familiar para todos los usuarios.

La autenticación con username y contraseña admite varias modalidades en Auth0. Si su aplicación es nueva y no tiene una base de usuarios existente, una Conexión de base de datos preconfigurada de Auth0 le proporcionará todo lo necesario para empezar a autenticar a sus usuarios. Sin embargo, si tiene un repositorio de usuarios heredado, como su propia base de datos de usuarios o un sistema LDAP existente, dispone de un par de opciones para migrar sus usuarios, como se explica en nuestra guía sobre la migración de usuarios.

Independientemente de cómo termine aprovisionando usuarios para su conexión de base de datos, la autenticación de esos usuarios es bastante similar. Requiere mostrar a los usuarios un formulario para introducir 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í su username y contraseña. 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.

​

Práctica recomendada

Recopilar credenciales solo en la página de inicio de sesión centralizada reducirá la superficie de exposición a posibles filtraciones de secretos de usuario. También reducirá la necesidad de recopilar credenciales innecesariamente. Consulte Universal Login para obtener más información.

​

Integración de la aplicació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, se exponen a riesgos de seguridad adicionales. Consulte Native Login para obtener más información.

Como ya se ha comentado, hemos comprobado que la mayoría de nuestros clientes usan OpenID Connect (OIDC) como protocolo estándar del sector para sus aplicaciones orientadas al cliente. Su primera tarea es determinar qué flujo de OIDC debe usar, y le recomendamos empezar revisando nuestra guía de grant mapping.

Si quiere permitir que usuarios anónimos accedan a alguna parte de su aplicación, debe decidir si los redirigirá de inmediato o si solo los redirigirá 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 acceder mediante deep links a una versión protegida (o área) de su sitio, tendrá que determinar qué enlaces a su aplicación provocarán una redirección automática a Auth0.

​

Acceso anónimo

Es importante tener en cuenta la experiencia del usuario cuando alguien llega por primera vez a su aplicación. Si su aplicación admite el acceso de usuarios anónimos (algo bastante común en las aplicaciones de comercio electrónico), hay distintos escenarios que debe considerar:

• Si vuelven a la aplicación después de haber iniciado sesión antes, o

• Si es la primera vez que acceden a la aplicación:

  • Si ya han accedido a otra aplicación que usa el mismo inquilino de Auth0,
  • Si alguna vez se han autenticado en este dispositivo o navegador (o si no lo han hecho desde hace mucho tiempo).

Cuando un usuario anónimo accede a su aplicación, a menudo conviene que la aplicación detecte si el usuario ya ha iniciado 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 ha iniciado sesión, podría hacer que el encabezado de la interfaz de usuario de la aplicación omita el botón de inicio de sesión y muestre en su lugar un menú de cuenta o perfil. Para ello, le convendrá usar 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. Después, la aplicación puede mostrar un botón de inicio de sesión si es necesario. Sin embargo, si el usuario ya ha iniciado 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 limitaciones de tasa.

Las llamadas a la Management API están sujetas a la política de limitación de tasa de Auth0. Debe tener esto en cuenta y, para facilitarlo, Auth0 suele recomendar el uso del SDK de Auth0 adecuado para su entorno de desarrollo en lugar de llamar directamente a nuestras API.

​

Enlaces profundos a endpoints protegidos

Hay varios 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 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 servidor de autorización lo devuelva a tu aplicación, puedes redirigirlo al lugar al que quería ir en primer lugar.

​

Práctica recomendada

La mayoría de los frameworks de autenticación modernos admiten middleware para redirigir a un servidor de autorización como Auth0. Al elegir uno, estas son algunas consideraciones clave:

• Compatibilidad con clientes confidenciales, clientes no confidenciales o ambos
• Compatibilidad con la configuración mediante endpoint de descubrimiento o mediante configuración explícita en línea
• Compatibilidad con la validación de tokens, incluidas la expiración, las firmas, las claims y los alcances
• Compatibilidad con Tokens de actualización si es necesario

​

Autenticación del usuario

La autenticación es el proceso de determinar la identidad del usuario. El resultado de la autenticación en un contexto de OIDC es un ID Token. Este token contiene información sobre el usuario y solo debería poder obtenerse si el usuario se autentica con uno o más factores, según lo defina el Servidor de autorización (la forma más común es el ID de usuario y contraseña). Hay algunos aspectos adicionales que quizá deba tener en cuenta además de obtener un ID Token:

• ¿También necesitamos un Token de acceso para llamar a una API compartida?
• ¿Su aplicación es una aplicación de página única y solo requiere un ID Token? Consulte Authorization Code Grant with PKCE para obtener más información.
• ¿Su aplicación es una aplicación nativa (móvil o de escritorio) y/o necesita un Token de actualización? Consulte Authorization Code Grant with PKCE para obtener más información.

Antes de pasar a producción, debe asegurarse de que solo estén habilitados, para cada aplicación, los grants que está utilizando en la configuración de la aplicación.

​

Flujo de código de autorización (con o sin PKCE)

Si su SDK solo admite el flujo de código de autorización, o necesita un Token de acceso o un Token de actualización, entonces el flujo de código de autorización (con o sin PKCE) también puede usarse para obtener un ID Token. El flujo 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 todo lo que necesita es el ID Token. En muchos casos, se implementa el flujo híbrido para proporcionar un acceso óptimo al ID Token y, al mismo tiempo, aprovechar el flujo 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 flujo 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, entonces debe usar el flujo de código de autorización.

​

Protección contra ataques

Los sistemas de autenticación son importantes porque evitan que los actores maliciosos accedan a aplicaciones y datos de los usuarios a los que no deberían tener acceso. Queremos interponer tantas barreras como sea posible entre esos actores maliciosos y el acceso a nuestros sistemas. Una de las formas más sencillas de lograrlo es asegurarse de que su protección contra ataques con Auth0 esté configurada correctamente, así que dedique un momento a revisar la guía sobre este tema y compruebe que funciona correctamente en su caso.

​

Práctica recomendada

Auth0 gestiona la detección de anomalías en segundo plano y ofrece una excelente funcionalidad 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 habilitar el envío de correos electrónicos a sus usuarios.

​

SSO con sistemas heredados

En una reestructuración a gran escala, no siempre es posible —ni práctico— actualizar todas sus aplicaciones al mismo tiempo. De hecho, nuestra práctica recomendada es planificar un enfoque iterativo para la integración con Auth0. Si sus aplicaciones ya usan inicio de sesión único (SSO) y su sistema de identidad heredado admite protocolos como OIDC o SAML, tiene un par de opciones si desea seguir ofreciendo SSO mientras se integra con Auth0:

• Actualice el proveedor de identidad existente en su sistema SSO heredado para que redirija a Auth0 para el inicio de sesión (por ejemplo, mediante SAML), o
• Configure Auth0 para que redirija a su sistema SSO heredado para iniciar sesión. Para ello, debe configurar su sistema heredado como un Proveedor de identidad (IdP) en Auth0 (es decir, mediante SAML o OIDC).

​

Práctica recomendada

Mantener 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 se integra con Auth0. Si planea seguir este enfoque, contemplarlo desde el principio puede ayudar a garantizar que sea viable. 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 requiera investigación 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 a sus usuarios desde sus aplicaciones a un sistema centralizado para autenticarlos, y ese sistema solo solicita credenciales si aún no tienen una sesión con el sistema centralizado, entonces tiene una implementación heredada de SSO.

​

Autenticación social

El escenario de “trae tu propia identidad” que ofrecen Facebook, Google, etc. es una valiosa forma 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 sociales con una interrupción mínima.

Auth0 proporciona una forma sencilla de probar conexiones sociales mediante claves de desarrollador preconfiguradas. Sin embargo, estas tienen limitaciones, y antes de pasar a producción, tendrás que configurar tus propias claves específicas de la aplicación siguiendo las instrucciones del proveedor o proveedores sociales que elijas.

Con la compatibilidad con el inicio de sesión social, las identidades y credenciales de los usuarios son administradas por el proveedor social, al igual que determinados atributos de identidad, que Auth0 usará para completar el perfil del usuario. Auth0 también puede proporcionar acceso a los Tokens de acceso de los Proveedores de identidad (IdP) sociales, para que tu aplicación también pueda llamar a APIs de IdP sociales de terceros en nombre del usuario.

​

Práctica recomendada

El inicio de sesión social es una excelente funcionalidad, pero cuando ofreces más de una forma de iniciar sesión, debes tener en cuenta la posibilidad de que tus clientes realmente usen varias. De manera predeterminada, cada identidad de usuario en Auth0 tiene su propio perfil de usuario, por lo que probablemente querrás considerar la capacidad de Auth0 para vincular cuentas de usuario y así proporcionar una forma eficaz de asociar un perfil de usuario con múltiples identidades.

La extensión Custom Social Connections de Auth0 amplía aún más la autenticación social al permitirte conectarte con cualquier proveedor externo compatible con OpenID Connect (OIDC) que no tenga soporte nativo. Por ejemplo, la compatibilidad con el proveedor de identidad emitido por el gobierno SwissID se puede configurar en Auth0 mediante una Custom Social Connection.

​

Autenticación multifactor (MFA)

En una época en la que el uso indebido de las credenciales de los usuarios alcanza niveles sin precedentes, proteger sus sistemas supone un desafío, especialmente cuando el robo de información de identidad es tan habitual. 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. Esto se conoce más comúnmente como autenticación multifactor. Así se 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.

​

Práctica recomendada

Es bastante común 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 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 una barrera de segundo factor flexible y eficaz:

• Auth0 Guardian: un servicio que proporciona tanto la generación de notificaciones Push como una aplicación para aprobar o rechazar solicitudes. Push envía notificaciones al dispositivo previamente registrado de un usuario —normalmente un móvil o una tableta—, desde el que puede aprobar o rechazar inmediatamente el acceso a la cuenta con solo pulsar un botón.
• Contraseña de un solo uso basada en el 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 solicita al usuario antes de que pueda completar la autenticación.
• Voz: para entregar un código de un solo uso mediante una llamada telefónica que luego se solicita al usuario antes de que pueda 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 mediante 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.

​

Guía de planificación de proyectos

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 B2C