L’implicit flow, le flow pour les applications SPA ? Plus pour longtemps…

Après avoir vu la notion de modern authentication et deux notions clefs de l’authentification (applications et consentement), continuons ce Mois de l’Identité avec le flow implicit OAuth2.

Implicit flow

Le flow implicit OAuth2 a été conçu et est utilisé principalement pour les applications SPA (monopage Javascript) lors de l’appel à des APIs tierces. Celles-ci valident les jetons d’accès négociés par l’application avec le fournisseur d’identité.

À noter : dans ce cas, il n’y a pas de jeton d’actualisation émis. L’actualisation du jeton d’accès s’effectue directement dans la page (iframe masqué en général). Si la session avec le fournisseur d’identité est encore active (ou autre mécanisme de sauvegarde de l’authentification spécifique à l’IDP), ce sera transparent pour l’utilisateur.

Ci-dessous le schéma du flux d’octroi :

Ce flux est assez simple à tester : il suffit de créer une application (en savoir plus sur le concept d’application) afin d’avoir un identifiant (ClientID) et, bien sûr, un fournisseur d’identité (Azure AD par exemple). Il faudra ensuite simuler le premier appel vers le endpoint d’authentification dans un navigateur :

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=REPLACE_WITH_CLIENT_ID&response_type=token&redirect_uri=https://localhost&response_mode=fragment&state=12345&nonce=678910&scope=openid

Après le processus d’authentification et consentement de l’utilisateur (si ce n’est pas déjà fait) sur le provider d’identité, celui-ci le redirige vers l’url de redirection (paramètre redirect_uri) avec le token émis :

https://localhost/#access_token=ACCESSTOKEN &token_type=Bearer&expires_in=3599&scope=profile+openid+email&state=12345&session_state=c96c7460-a73b-48c4-8818-66e74d8e838e

Dans le cadre d’un développement, il est fortement conseillé d’utiliser la librairie fournie par le fournisseur d’identité : en effet, celle-ci simplifie, par abstraction des protocoles, l’authentification, les redirections, l’acquisition, l’actualisation et la mise en cache des tokens.

Prenons un exemple avec MSAL for JS et Azure AD (https://www.npmjs.com/package/msal) :

• Créer une application de type monopage ou SPA
• Installer le package MSAL

Npm install msal

• Créer un fichier Config.ts
• Ajouter les 2 constantes suivantes :

1. export const appId= '<APPID>';

2. export const scopes= ["User.Read"];

• Dans le fichier App.tsx, il faut importer puis utiliser la classe permettant d’instancier l’application.
• Changer la définition de la classe afin d’y introduire un état authentifié :

1. class App extends react.Component<{},{isAuthenticated:boolean}>

•  Ajouter les lignes suivantes en haut du fichier

1. import { UserAgentApplication} from 'msal'; 
2. import { appId, scopes } from './Config';

•  Ajouter la propriété suivante :

1. userAgentApplication: UserAgentApplication;

• Ajouter la configuration suivante dans le constructeur :

1. var msalConfig = {
2.       auth: {
3.        clientId: appId
4.      }
5.    };
6.    this.userAgentApplication = new UserAgentApplication(msalConfig);
7.    this.state = {
8.      isAuthenticated: false
9.    };

• Nous allons maintenant modifier la barre de navigation afin d’y ajouter les informations et actions de login :

1. <NavBar isAuthenticated={this.state.isAuthenticated}

2. authButtonMethod={this.state.isAuthenticated ? this.logout.bind(this) : this.login.bind(this)}

3. user={{}} />

• Puis compléter les méthodes login et logout :

1.async login() {
2.    try {
3.      var loginRequest = {
4.        scopes: scopes    
5.      };
6.      await this.userAgentApplication.loginPopup(loginRequest);
7.       this.setState({
8.        isAuthenticated: true,
9.      });
10.    }
11.    catch (err) {
12.      var errParts = err.split('|');
13.      this.setState({
14.        isAuthenticated: false,
15.      });
16.    }
17.  }

1.  logout() {
2.    this.userAgentApplication.logout();
3.  }

• Notre utilisateur est maintenant connecté !

Migrer vers MSAL 2 et le flux par code et PKCE

Le flux implicite OAuth 2.0 vu précédemment est encore utilisable mais est voué à disparaître au profit du flux d’octroi par code d’autorisation avec clé (PKCE). En effet, les paramétrages par défaut de sécurité des navigateurs modernes ayant évolué (ITP dans Safari, par exemple), une partie de l’implémentation de flux implicite (silent authentication pour le renouvellement de token) ne peut plus fonctionner (car basé sur un échange de cookies cross domaine à l’aide d’iframe). Pour cela, les bonnes pratiques conseillent d’utiliser un autre flux (authorization code avec PKCE) permettant d’obtenir un refresh token. Pour plus de détails sur ce flux, je vous invite à consulter notre prochain article.

Pour prendre en compte ce changement, Microsoft a fait évoluer sa librairie MSAL (v2 sortie en GA fin juillet 2020). Nous allons voir ici les modifications (minimes) que cela entraine :

1. Premier point : le package npm se nomme « msal-browser » dorénavant. Il est donc nécessaire de l’installer :

npm install @azure/msal-browser

2. Ensuite, importer la classe « client » qui a changé :

import { PublicClientApplication } from '@azure/msal-browser';

3. Celle-ci s’instancie de la même manière (paramètre MSAL configuration) :

new PublicClientApplication

4. Notez qu’un certain nombre de méthodes ont disparu : c’est le cas de getAccount, utilisée pour récupérer les informations du compte connecté. À la place, nous retrouvons une méthode équivalente qui renvoie un tableau de comptes connectés (getAllAccounts).

5. Ce changement impacte aussi la méthode de récupération du token où il faut maintenant préciser le compte :

6. Dernière étape (ou plutôt première… mais bon, j’aime le test & fail 😊), il s’agit de changer la configuration de l’application Azure AD utilisée pour accepter le nouveau flow. Et dans ce cas, bonne nouvelle, l’interface d’Azure a déjà tout prévu ! En arrivant sur la page de configuration de notre application, Azure nous propose donc de migrer nos urls :

7. Nous retrouvons donc notre utilisateur connecté, mais cette fois-ci à travers un flux plus pérenne.

Nous avons donc vu à travers ces exemples d’implémentation d’une application de type SPA que le flux implicite reste très simple à mettre en place même s’il est amené à être de moins en moins utilisé pour les nouvelles applications au profit du flux « authorization code & PKCE » qui devient un standard dans la plupart des scénarios d’application (Web, Mobile et maintenant SPA).

Une démo pour appliquer la théorie :

Dans le cadre de ce Mois de l’Identité, nous vous invitons à visionner le replay de notre webinaire exclusif. Nos experts ont présenté une application sans authentification, sur laquelle ont été appliqués les différents principes présentés dans nos articles de blog. Pour visionner le replay, il vous suffit de cliquer sur la bannière ci-dessous !