Maîtriser l'acquisition d'Access Token : Client Credentials Flow

Cet article fait partie d’une série. Dans celui-ci, nous mettons en avant le flux Client Credentials. Consultez les autres articles sur les autres flux d’autorisation :

• Maîtriser l’acquisition d’Access Token : le flux Authorization Code
• Maîtriser l’acquisition d’Access Token : Utiliser un refresh token
• Maîtriser l’acquisition d’Access Token : Utiliser un certificat

Un autre flux d’authentification important dans le domaine OAuth 2.0 est le flux Client Credentials. Contrairement au flux Authorization Code, le flux Client Credentials fonctionne sans nécessiter d’interaction utilisateur.

Dans le flux Client Credentials, le processus d’obtention d’un access token est remarquablement simplifié. Avec une seule requête POST vers l’endpoint token désigné, et l’inclusion du client ID et du client secret de votre application, vous pouvez acquérir l’access token. Cette efficacité est particulièrement avantageuse dans les scénarios où l’application interagit avec des APIs ou des services en son propre nom, plutôt que de représenter un utilisateur.

L’un des principaux avantages du flux Client Credentials est sa simplicité. Les exigences minimales d’un client ID et d’un client secret contribuent à un processus d’autorisation accéléré, ce qui est particulièrement précieux lorsque l’acquisition rapide de tokens est essentielle pour maintenir la fonctionnalité de l’application.

Cependant, il est important de noter que cette efficacité s’accompagne de compromis. Une distinction importante du flux Client Credentials est qu’il ne produit pas de refresh token. Les refresh tokens, tels qu’obtenus via d’autres flux, permettent des sessions prolongées sans nécessiter d’authentification répétée de l’utilisateur. Dans le flux Client Credentials, l’absence de refresh tokens signifie que lorsque l’access token expire, l’application doit se ré-authentifier et obtenir un nouvel access token en utilisant les credentials client (client ID et client secret).

Vous pouvez effectuer une requête POST vers https://login.microsoft.com/[YOUR_TENANT_ID]/oauth2/v2.0/token avec les paramètres suivants dans le body de la requête :

• client_id : L’identifiant de votre client, trouvable dans l’écran d’accueil de votre inscription d’application.
• client_secret : Le client secret de votre client ID. Vous pouvez le générer dans la section Certificates & secrets de votre inscription d’application dans Azure.
• grant_type : client_credentials
• scope : Le scope doit être l’identifiant de ressource de l’application contre laquelle vous souhaitez utiliser votre access token, suivi de .default. Pour Microsoft Graph, ce serait par exemple https://graph.microsoft.com/.default.

Si tout se passe bien, vous obtenez un json en retour qui contient votre access token :

Comme un lecteur l’a fait remarquer à juste titre dans un précédent article, la sécurité doit toujours être prise en compte lors de l’utilisation de ce type de flux d’autorisation.

Les client secrets sont essentiels dans OAuth 2.0 pour l’authentification des clients, mais leur sécurité varie selon les contextes côté serveur et côté client.

Dans l’utilisation côté serveur, les client secrets sont mieux protégés car ils peuvent être stockés de manière sécurisée, par exemple dans un fichier de configuration ou avec Azure Key Vault. Cependant, dans le scénario côté client, exposer les secrets dans le code augmente la vulnérabilité. Pour renforcer la sécurité, il est recommandé de limiter l’exposition côté client, en utilisant des flux basés sur des tokens dans la mesure du possible ou en optant pour la gestion côté serveur des opérations sensibles.