A pesar de mi corta experiencia laboral, por suerte o por desgracia me he visto en la tesitura de tener que configurar la autenticación de una SPA desarrollada en angular mediante Azure AD. Este es un proceso que realmente no es muy complejo, pero si tienes cero conocimiento de la materia (como fue mi caso) o no lo has hecho nunca, puede llegar a resultarte una tarea extremadamente compleja, incluso imposible.
Habiendo pasado ya tiempo de aquello, mi conocimiento con respecto a este tema se ha ampliado, y teniendo en cuenta mi experiencia y que ya he sido consultado por algún compañero respecto a este tema, he creído que sería una gran idea explicar este proceso. Sin más dilación, manos a la obra.
Instalaciones y requisitos previos
En primer lugar, hemos de crear una instancia de Azure Active Directory (AD). Para ello has de dirigirte al siguiente enlace https://portal.azure.com
Una vez creada dicha instancia y configurada la aplicación que queremos registrar, hemos de tomar nota de los siguientes valores:
- client_id
- tenant_id
- redirect_uri
Estos valores nos serán de suma importancia a la hora de configurar en nuestro proyecto el módulo de autenticación.
Además, en tu proyecto de angular has de realizar las siguientes instalaciones:
npm install @azure/msal-browser @azure/msal-angular
Configuración del módulo de autenticación y protección de rutas
Para centralizar toda la configuración de autenticación con Azure AD, vamos a crear un módulo en el que implementemos la configuración básica, así como el flujo de autenticación. Para entenderlo mejor, veremos un ejemplo de configuración y explicaremos punto por punto el código implementado
En primer lugar, vamos a importar de ‘@azure/msal-angular’ el módulo ‘MsalModule’. Aquí será donde realizaremos todas las configuraciones pertinentes:
- PublicClientAplication: En la instanciación de este objeto vamos a indicar, entre otras cosas el clientId, tenandId y la redirectUri. Recordemos que estos datos los obtuvimos en el primer paso cuando creamos una instancia en Azure AD. También establecemos la ubicación en la que se almacenará el estado de sesión del usuario, que en este caso es el localStorage. La constante ‘isIE’ se utiliza para verificar si el usuario está accediendo a nuestra aplicación vía Internet Explorer (IE) o con otro explorador. Esta verificación es necesaria puesto que IE tiene ciertas peculiaridades acerca del manejo de la autenticación con Azure: IE no admite el almacenamiento en el localStorage para guardar el estado de autenticación del usuario, de tal forma que si la constante ‘isIE’ es ‘true’, se configurará ‘storeAuthStateInCookie’ en la configuración de MSAL para almacenar dicho estado de autenticación en una cookie.
- A continuación, indicamos el flujo de autenticación que queremos que siga nuestra aplicación, el cual puede ser vía redireccionamiento o vía pop up.
- El objeto ‘authRequest’ contiene la información de solicitud de la autenticación. El ‘scope’ hace referencia al ámbito o ámbitos solicitados durante la autenticación. Estos ámbitos representan los permisos y recursos a los que queremos acceder en relación al usuario que está realizando la autenticación. Entre los distintos scopes que podemos indicar se encuentran:
- ‘openId’: Permite obtener un id de autenticación única de usuario.
- ‘profile’: Proporciona detalles básicos del perfil de usuario, tales como el nombre y foto de perfil.
- ‘user.read’: Proporciona información adicional del usuario, tales como la dirección y el número de teléfono
Estos son solo algunos de los scopes que podemos indicar.
- Para terminar la configuración del módulo autenticación, indicamos el objeto en el que estableceremos los distintos recursos protegidos. En primer lugar, hemos de indicar una instancia de la API de Microsoft Graph: ‘https://graph.microsoft.com/v1.0/me’. Al incluir esta configuración, le indicamos a MSAL y a Azure AD que al realizar solicitudes HTTP a la url de Microsoft Graph especificada, hemos de tener un token de acceso válido con el ámbito o scope especificado (en este caso es ‘user.read’). En esta configuración podemos agregar más recursos protegidos con sus correspondientes ámbitos de configuración. Esto nos va a permitir especificar qué recursos adicionales de Microsoft o de otras API externas necesitamos acceder y los permisos requeridos para obtener dicha información.
Lo único que nos queda por establecer en este módulo son los providers. Además de las clases MsalService y MsalGuard (de la cual hablaremos más adelante), podemos ver que le estamos proveyendo un objeto. Este objeto es de suma importancia, puesto que de esta forma a todas las peticiones HTTP salientes les va a incluir en la cabecera un token válido de acceso a los recursos protegidos, los cuales indicamos anteriormente.
Ahora sí, hemos terminado toda la implementación del módulo de autenticación, y simplemente tendremos que importar dicho módulo en el módulo raíz de nuestro proyecto.
Implementación del flujo de inicio de sesión
Lo siguiente que veremos será el flujo que seguirá nuestra aplicación. Pongamos que tenemos el siguiente archivo de rutas
La constante isIframe es una evaluación de si nuestra aplicación se está ejecutando dentro de un iframe y no fue abierta dentro de otra ventana. Esta verificación puede ser útil en ciertos escenarios en los que se necesite adaptar el comportamiento o la interfaz de usuario de la aplicación cuando se ejecuta dentro de un iframe.
Dentro del componente HomeComponent tendremos la siguiente configuración.
Donde las importaciones que debemos realizar son estas
En primer lugar, llamamos a la función ‘prepareLoginConfig’. Aquí lo que hacemos es escuchar los eventos de progreso de autenticación, y cuando estos terminan, llamamos a la función ‘setLoginDisplay’ para ver si hay alguna cuenta autenticada, almacenando dicho resultado en la variable ‘loginDisplay’, la cual nos servirá para mostrar alternativamente los botones de login y logout.
En la función de login comprobamos si se ha configurado una solicitud de autenticación (authRequest) en la configuración del msalGuard (MsalGuardConfig). Tanto si se haya configurado como no, al ejecutar esta función hacemos la redirección a la página de autenticación de Azure AD.
Para implementar la función de logout, basta con hacer lo siguiente
Para finalizar veremos cómo proteger las distintas rutas de nuestra aplicación, asegurándonos así de que un usuario que no esté autenticado no tenga acceso a ellas.
Protección de rutas
Si nos fijamos en la siguiente imagen, nuestro archivo de rutas ha cambiado un poco. A la página de profile le hemos añadido el guard ‘MsalGuard’, el cual importamos de ‘@azure/msal-angular’. Esto hará que, al intentar acceder a dicha página, comprobará si tenemos un token válido de autenticación y, en caso de no tenerlo, nos negará el acceso mostrándonos a continuación la página de autenticación de azure, vía redirección o vía pop up según hayamos configurado.
Consideraciones finales
He de puntualizar que el ejemplo aquí desarrollado se ha hecho para la versión v2 de la librería @azure/msal-angular, la cual sigue actualmente en mantenimiento y está disponible para las versiones de la 9 a la 14 de angular (ambas inclusive).
Para versiones superiores de angular está ahora mismo en desarrollo la versión v3, y para las versiones de la 6 a la 9 (también incluida) de angular tenemos la versión v1, la cual también sigue en mantenimiento.
Las versiones 4 y 5 de angular disponen de la versión v0 de esta librería, pero ya no se le sigue dando soporte.
