Azure AD B2C es un excelente servicio para el manejo de inicio de sesión y registro de usuarios que además ofrece integración con redes sociales.

Uno de los aspectos negativos es que no ofrece ningún tipo de mecanismo para unificar usuarios, o al menos para prevenir su duplicación, cuando el email es el mismo.

En este post analizaremos en detalle que herramientas Azure AD B2C nos provee y crearemos una propuesta de arquitectura para detectar usuarios duplicados. En los próximos artículos completaremos la implementación.

Contexto

Dentro de Azure AD B2C existe el concepto de Proveedor de Identidad, el cuál representa el servicio dueño de la identidad virtual de los usuarios.

Ejemplos de proveedores de identidad pueden ser Google o GitHub, los cuáles son externos, ya que son ellos los responsables por la información de los usuarios.

Pero también tenemos la opción de utilizar email y contraseña y que Azure AD B2C se encargue de la identidad. Este proveedor se denomina Local.

Caso de uso

Un usuario opta por registrarse mediante el proveedor local (con email y contraseña) con el email usuario@gmail.com.

Sin embargo, más tarde inicia sesión con GitHub utilizando el mismo email. Es bastante frecuente que el usuario olvide el primer inicio de sesión.

Si bien se utilizaron dos proveedores de identidad diferentes (Local y GitHub), la identidad de usuario es la misma.

Azure AD B2C no ofrece un mecanismo para detectar estos casos, lo que deriva en la creacion de dos perfiles de usuarios diferentes.

Solución

Azure AD B2C crea una identidad de usuario para cada usuario nuevo que se registra, independientemente de qué proveedor se haya utilizado.

Tabla comparativa usuario Local y GitHub
Tabla comparativa usuario Local y GitHub

La solución “ideal” sería unificar las identidades en los casos donde el email es el mismo, sin embargo eso implica escribir “Políticas personalizadas” y es mucho más complejo (Escribiré una serie de posts dedicados exclusivamente a esto).

Una solución parcial, pero eficaz y eficiente, consiste el prevenir la creación de un usuario si ya existe un usuario con el mismo email (sea de un proveedor externo como local).

Conectores de API

Los Conectores de API es una forma de integrar nuestro flujo de usuario con REST APIs para poder realizar validaciones o ejecutar reglas de negocio antes de la creación de un usuario.

Los conectores pueden ser llamados en dos momentos específicos:

  • Después de haber iniciado sesión con un proveedor de identidad externo. Este conector se ejecuta solo para inicios de sesión con proveedores externos y antes de completar el formulario con los atributos de usuario.
  • Antes de crear el usuario. Este conector se ejecuta después de completar el formulario de atributos de usuario y antes de la creación del usuario.
Diagrama de flujo de conectores
Diagrama de flujo de conectores

Los Conectores de API son invocados únicamente durante el registro de un usuario, ya sea con un proveedor externo o local, y no durante el inicio de sesión.

Microsoft Graph API

El equipo de Microsoft ha creado una REST API estándar llamada Graph API la cuál nos va a permitir interactuar con Azure AD B2C.

Una de las caracteristicas que nos interesa es la de poder consultar la base de datos de usuarios de Azure AD B2C.

Propuesta

Hasta el momento tenemos los Conectores de API para ejecutar REST APIs y Microsoft Graph API para obtener información de la base de datos de usuarios.

Nos falta una pieza fundamental para completar la solución: una REST API que sea ejecutada por un Conector e interactúe con Graph API.

Para esto vamos a utilizar Azure Functions. No sólo es muy fácil de integrar y económico, sino también simple de utilizar. Al ser un servicio serverless, no tenemos que preocuparnos por la infraestructura, sino solo de nuestro código.

Propuesta de arquitectura

Nuestra API recibirá como parte de la petición el email con el que se está iniciando sesión y validará contra Microsoft Graph API si ya existe un usuario con ese mismo email en nuestro tenant de Azure AD B2C. En caso de existir devolverá un código de estado de error (400 – Bad Request), caso contrario un código de estado de éxito (200 – Ok).

El Conector de API leerá el código de estado devuelto y continuará con el flujo d ejecución si el código es exitoso, o detendrá el flujo y mostrará al usuario un error si el código no es exitoso.

Próximos Pasos

Ya con la propuesta en pie, estamos en condiciones de comenzar a crear los componentes necesarios para la implementación de la solución.

No te pierdas el próximo post donde vamos a comenzar a crear los Conectores de API junto con una Azure Function base que nos va a permitir entender la propuesta.