Microsoft Identity Platform est le fournisseur d’identité de Microsoft, autrement dit il permet à votre application d’authentifier ainsi qu’autoriser des utilisateurs ou d’autre applications à avoir accès à celle-ci. Microsoft Identity Platform prend en charge deux types de protocoles, OAuth 2.0 et OpenID Connect qui englobe tous les types d’architecture des applications modernes. Cet article a pour but de décrire les différents flux d’authentification de manière simple.

Comment se passe une authentification moderne ?

Aujourd’hui l’authentification se passe en deux temps, dans un premier temps le client va demander l’accès à une application, l’application va par la suite le rediriger vers l’Identity Provider avec qui il a une relation de confiance (ici Microsoft Identity platform) pour s’authentifier, à l’aide d’un mot de passe ou autre, si l’utilisateur est reconnu il recevra un token de sécurité qui sera renvoyer à l’application, celle-ci décodera le token de sécurité a l’aide d’une clé publique de l’identity provider, il autorisera ensuite l’utilisateur a utilisé l’application, pour que cela soit plus clair voici un schéma :

Le token de sécurité contient plusieurs informations importantes, tel que l’audience( application pour laquelle il est destiner), l’expiration (sa durée de vie), des réclamations ( information sur l’utilisateur),  etc.

Les Tokens de sécurité peuvent être obtenus par plusieurs types d’application :

  • Applications monopages
  • Applications clientes publiques
  • Applications clientes confidentielles (API)

Le scénario décrit ci-dessus change légèrement en fonction du type d’application néanmoins le principe de base reste le même. Je vais maintenant vous présenter chacun des cas pour chaque type d’application.

Les Applications Monopage :

Microsoft Identity Platform gère l’authentification des application monopage en envoyant 2 types de token de sécurité. Un token d’accès contenant les informations d’authentification pour permettre d’accéder à une API et un token ID qui contient les informations sur l’utilisateur. Les applications monopage sont souvent codées à l’aide de JavaScript ou d’un framework SPA, comme Angular, Vue.js et React.js et sont exécutées dans un navigateur web.

Le Flux implicite est une méthode d’authentification simple, le client va rediriger l’utilisateur vers un Identity provider qui va lui fournir les Tokens dont il aura besoin. Cependant ce mode d’authentification ne prend pas en charge les token d’actualisation qui permet au client de redemander un accès a la fin de la durée de vie du token d’accès.

Application web qui connecte un utilisateur et appelle une API web pour le compte de l’utilisateur :

Ce genre d’application s’authentifie grâce a un flux de code d’autorisation. Dans ce type de flux c’est le client qui fait une demande explicite pour être autoriser ainsi que pour avoir accès au token d’accès, que le client recevra après avoir validé sont autorisation de token d’accès.

Après avoir reçu les token demandés, les applications les stockerons dans le cache, ces Tokens seront actualisés de manière silencieuse par le contrôleur.

Application de bureau qui appelle une API web pour le compte d’un utilisateur connecté :

Pour authentifier une application bureau auprès d’une API Web, Microsoft Identity Platform a recours a la bibliothèque MSAL, Avec ces méthodes interactives, cependant MSAL utilise le navigateur web.

Vous pouvez donc utiliser trois types de flux pour récupérer votre token d’accès :

  • Flux de code d’autorisation (vue plus haut)
  • Authentification Windows intégrée qui consiste à récupérer un token en silence, cependant il y a plusieurs contraintes qui se doivent d’être respectées :
    • l’utilisateur doit être fédéré (Utilisateurs créés dans Azure AD ou Active directory) ;
    • ne fonctionne uniquement pour les applications écrites pour les plateformes .NET framework, .Net Core et UWP ;
    • ne gère pas les authentifications Multifacteurs.
  • Flux d’utilisateur et mot de passe, il consiste a demander a l’utilisateur son mot de passe et son identifiant cependant il est déconseiller par Microsoft.

Il existe une autre possibilité pour les appareils sans navigateur intégrés. Le flux de code d’appareil :

Le flux de code d’appareil consiste à avoir recours à un second appareil (autre ordinateur ou téléphone ) muni d’un navigateur web pour se connecter de manière interactive. Cette authentification se passe de 2 étapes :

  • Tout d’abord l’application affiche un code de sécurité que l’utilisateur devra saisir depuis le second appareil (ex : son téléphone) sur une URL délivré en même temps que ce code.
  • Une fois l’authentification réussie, l’application de ligne de commande recevra les jetons de sécurité requis via un canal arrière et l’utilisera pour effectuer les appels d’API Web dont elle a besoin.

Cependant ce genre d’authentification ne fonctionne que depuis une application publique.

Application mobile qui appelle une API web pour le compte d’un utilisateur interactif :

Cette authentification fonctionne avec le flux d’autorisation expliqué plus haut. MSAL iOS et MSAL Android utilisent le navigateur web du système par défaut.

 

API web qui appelle une autre API web pour le compte d’un utilisateur :

Lors de ce cas de figure votre API doit obtenir le token de sécurité en aval de l’appel à l’autre API. Ce flux s’appelle le flux service a service. La partie de l’inscription d’application liée aux autorisations de l’API est classique. La configuration de l’application implique l’utilisation du flux OBO OAuth 2.0 afin d’échanger le jeton du porteur JWT contre un jeton pour une API en aval. Ce jeton est ajouté au cache de jetons, où il est disponible dans les contrôleurs des API web, et peut ensuite obtenir un jeton en mode silencieux pour appeler des API en aval.

 

Application démon qui appelle une API web dans le nom du démon :

Vous pouvez parfois avoir besoin de qu’une application face des appels a une autre application sans l’intervention d’un utilisateur, pour cela vous devez définir un secret lors de l’inscription de votre application dans Azure AD. Par la suite de cela lors des appels à l’application voulu vous devrez passer en cache son secret. Ce secret peut être constituer du mot de passe de l’application ainsi que différentes informations nécessaires à son appel. Ce flux s’appelle Flux d’informations d’identification client

Ceci est un article des Experts Infeeny avec Kevin ANSARD.