Modern Authentication : concepts et défis de l’authentification moderne dans les applications

Dans notre vidéo d’introduction, nous avons abordé brièvement la notion « d’authentification moderne » et les challenges auxquels elle doit faire face. Nous verrons ici ses différents éléments à travers la présentation de la plateforme d’identité Microsoft : Azure Active Directory (Azure AD ou AAD).

L’identité : pourquoi ? Comment ?

La notion d’identité : une nécessité

Rappelons d’abord pourquoi avoir une notion d’identité dans les applications est nécessaire :

• Sécurisation (menace externe) : le premier objectif, le plus évident, est d’empêcher une personne sans identité/compte d’accéder aux applications et aux données. C’est la notion la plus simple et la plus implémentée par les différents systèmes. Elle est couverte par les notions d’authentification (forte, multifacteur…) ;
• Habilitation et accès (menace interne) : deuxième objectif, pas toujours couvert, consiste à offrir un système permettant de gérer, plus ou moins finement, les accès à certaines ressources en fonction de l’identité connectée. On retrouve ici les différents mécanismes d’autorisation, rôle et assignation de groupes offerts par les fournisseurs d’identité ;
• Profiling : dernière notion importante (et pas assez utilisée à mon goût), le profiling, qui permet à l’application d’agir en fonction d’informations de l’utilisateur connecté et fournies par son identité. On retrouve ici les notions de claims et d’assertions.

Pourquoi utiliser un système dédié à l’identité ?

Pour couvrir l’ensemble de ces objectifs, il est fortement recommandé de déléguer à un système dédié l’ensemble des mécanismes décrits ci-dessus, quels que soient les protocoles et technologies utilisés (solutions SAAS, custom, etc.) :

• Niveau de sécurité : les fournisseurs d’identité tiers, principalement, garantissent un niveau de sécurité qu’il sera difficile à atteindre seul en gardant les même fonctionnalités et facilités d’accès ;
• Coût : ces systèmes sont en général peu coûteux, ne demandent que très peu de maintenance et sont relativement simples à implémenter ;
• Découplage : afin de garantir la séparation des responsabilités et l’indépendance des systèmes (déploiement, mise à jour, PRA…). Il faut a minima prévoir un système autonome et non-intégré dans les applications métiers ;
• Scénarios avancés : ils permettent la mise en place simple du SSO, de la fédération d’identité, du MFA, du Passwordless, etc.

Rappel des notions clefs autour de l’identité

Précisons ici quelques notions qui vont nous être utiles par la suite :

• Authentification : processus permettant au système de s’assurer de la légitimité de la demande d’accès faite par une entité (être humain ou un autre système…) afin d’autoriser l’accès de cette entité à des ressources du système (systèmes, réseaux, applications, etc.).
• Autorisation : ensemble des processus liés au contrôle d’accès comprenant à la fois la définition de ces accès (qui accède à quoi) ainsi que leur exécution (accès accordé ou non).
• Identité : ensemble des informations liées à un utilisateur.
• Ressource (protégée) : dans le cadre des protocoles OAuth (cf. plus bas), il s’agit des données ou services protégés par le système d’autorisation mis en place. On parle donc aussi parfois de « resource owner » pour désigner en général l’utilisateur connecté qui consent à l’accès à ses données par l’application.
• Client : également appelé Application (dans le cadre de Azure AD). Il s’agit de l’application, du service souhaitant accéder aux ressources.

Microsoft identity platform

Prenons notre exemple sur la plateforme d’identité fournie par Microsoft.

Un fournisseur d’identité complet

Cette plateforme représente l’ensemble des outils liés à l’identité de Microsoft.

On y retrouve donc les fournisseurs d’identité que sont Azure AD et Azure AD B2C prenant en charge l’authentification et les autorisations. Ils peuvent prendre en charge différents protocoles (OAuth 2.0, OpenID Connect, WS-Federation ou SAML 2.0). De plus, ils sont fournis avec des interfaces de gestion des répertoires d’utilisateurs et d’applications (inscriptions, autorisation, consentement, etc.).

Des ressources pour les développeurs

Dans cette notion de plateforme d’identité, Microsoft intègre l’ensemble des ressources fournies sur ce sujet, les bibliothèques (ADAL, OWIN, MSAL, Microsoft.identity.web…) proposant une simplification de l’implémentation par abstraction des protocoles. Elles sont disponibles dans de nombreux langages avec leurs documentations et exemples. Notons que Microsoft propose une vision par type d’application pour déduire les protocoles d’authentification à utiliser (mobile/native, SPA, Web, Daemon, Device…).

v1.0 ou v2.0 ?

La plateforme existe en deux versions, la v1 (obsolète) étant dénommée Azure AD for Developers. Celle-ci, comme son nom l’indique, était limitée à Azure AD et principalement utilisée dans le cadre des fédérations ADFS.

External identities (Azure AD B2C & B2B collaboration)

Afin de gérer les utilisateurs externes à l’entreprise, la plateforme d’identités Microsoft propose deux solutions regroupées sous le « produit » : External Identities » (factures communes).

Vous pourrez accéder ici à la documentation Microsoft External Identities (Mars 2021).

On retrouve donc deux systèmes orientés en fonction du type d’utilisateur visé : B2B et B2C.

Azure AD B2B collaboration

Le système d’invitation des utilisateurs externes de l’AAD permet d’ajouter des utilisateurs sans avoir à gérer leur compte d’accès. En plus du processus d’invitation (liens, consent) bien connu, il est aussi possible d’ajouter des fournisseurs d’identités gérés (Microsoft, Facebook, Google et tout fournisseur Saml ou WS-Fed). Afin de personnaliser l’expérience d’onboarding des utilisateurs, il y a toujours les APIs fournies à travers le graph mais aussi une nouvelle expérience de personnalisation de l’inscription des utilisateurs externes encore en preview.

Azure AD B2C

Bien sûr basé sur l’Azure AD (répertoire d’utilisateurs, gestion des applications, etc.), ce fournisseur d’identité orientée application end-user vient compléter l’offre de son grand frère AAD très orientée Entreprise. Il offre donc un nouveau tenant avec un ensemble d’interfaces et de stratégies d’authentifications personnalisables, certes parfois difficilement… et surtout l’intégration de nombreux providers d’identités gérées :

Les flux OAuth 2.0 et l’OpenID Connect

Il s’agit des principaux protocoles utilisés pour l’authentification (OpenID Connect) et les autorisations (OAuth 2.0). Leur implémentation se décline en plusieurs flux correspondant à des étapes basées sur des redirections et échanges d’informations (secret, code, token…).

Microsoft identity platform authentication flows & app scenarios | Microsoft Docs

Résumé des flux

Implicit grant

Protocole pensé pour les applications sans serveur (SPA, mobile). Il s’agit d’une version allégée permettant l’envoi du token sans partage des secrets de l’application. Le token est donc renvoyé à l’application cliente directement après l’authentification. Le token se retrouvant sur le poste client, cela peut amener à une interception/réutilisation de ce token en dehors des appels initiaux. De fait, ce flux est dorénavant déconseillé et doit être remplacé par le flux avec code d’autorisation et échange de clés (Autorisation code & PKCE) dès que possible.

Client credential grant

Il s’agit du protocole utilisé par les applications sans utilisateur. En effet, dans ce flux, seule l’identité de l’application est vérifiée à l’aide de ses ID et secrets (ex : login/mot de passe). Il est utilisé pour les applications de type daemon.

Authorization code (& PKCE)

Initialement pensé pour les application privée (applications web avec serveur), ce protocole offre le plus haut niveau de sécurité. En effet, le token n’est échangé qu’entre le fournisseur d’identité et le backend de l’application ; la validation de l’authentification s’effectue à travers un code temporaire transmis par le navigateur à l’application.
Afin de pouvoir utiliser ce flux avec des applications « public » (Mobile et SPA) qui n’ont pas de secret, il fallait pouvoir ajouter une couche de sécurisation afin d’éviter les interceptions/injections de code d’autorisation. Ainsi, un système de clé (PKCE – Proof Key for Code Exchange) prouvant l’identité de l’application appelante a été mis en place. Une clé est générée puis chiffrée par l’application, le résultat est envoyé avec la première requête d’autorisation afin d’être stocké par le fournisseur d’identité. Lors de la demande de token, le code initial ainsi que la méthode de chiffrement sont envoyés à la place du secret de l’application, permettant au fournisseur de valider qu’il s’agit bien de la même application qui a fait la demande d’authentification initiale puis la demande de token et qu’il n’y a pas eu d’interception du code d’autorisation.

On-behalf-of (OBO)

Ce flux est rarement implémenté dans les fournisseurs d’identité du marché (mais souvent dans leur roadmap). Il permet à une API d’appeler une autre API avec l’identité de l’utilisateur connecté. Basé sur un échange de tokens entre applications autorisées, il permet à la première application d’obtenir un token pour la seconde application, à partir du token utilisé par son client.

OAuth 2.0 Device code

Ce flux permet à une application sans navigateur Internet de s’authentifier. L’application demande au fournisseur un ensemble d’informations permettant à l’utilisateur de s’authentifier sur un navigateur (URL et code), et à l’application (code) de récupérer le token une fois l’utilisateur authentifié. Il est aussi très utilisé dans les CLI (Command Line Interface).

Resource owner password credential grant (non recommandé)

Ce flux permet d’authentifier l’utilisateur à l’aide de ses identifiants (login/mot de passe) collectés sur l’application et passés vers le fournisseur d’accès. Ce flux n’est à utiliser qu’en cas de confiance absolue envers l’application, si (et seulement si) tous les autres flux ne sont pas possibles/disponibles. Autant dire jamais.

Token

Dans le cadre de l’authentification OAuth, la sécurisation des échanges se fait à travers un token JWT. Il en existe plusieurs types utilisés dans les protocoles précédents :

• ID Token pour OpenID Connect : il sert à identifier (authentification simple) et ne comporte donc que les informations principales de l’utilisateur (pas de rôle/accès). Il est signé par l’IDP et doit être vérifié par les applications ;
• Access token : il sert à autoriser (autorisation) et comporte les informations liées aux accès de l’utilisateur connecté. Il est bien sûr aussi signé par l’IDP et doit être vérifié par les applications, ainsi que les scopes et rôles (accès) qu’il comporte. Il a une durée de vie assez courte et doit être passé à chaque appel vers les ressources.
• Refresh token : il sert à régénérer les tokens précédents sans réauthentifier l’utilisateur. Il est envoyé par l’IDP avec les autres tokens et a une durée de vie beaucoup plus longue. A noter : le refresh token n’est pas disponible dans tous les flux (flux implicite, par exemple).

Nous vous donnons rendez-vous pour le prochain article de cette série sur l’identité, pour évoquer le concept d’application et de service principal.