Applications et consentement

Pourquoi enregistrer une application dans Entra ID ?

Par défaut, seuls les utilisateurs humains se connectent à Entra ID via leur navigateur. Mais les applications — qu'il s'agisse d'un site web, d'une API ou d'un script automatisé — ont elles aussi besoin d'une identité pour interagir avec Microsoft 365 et ses API.

Enregistrer une application dans Entra ID permet de lui attribuer une identité unique, de définir précisément les ressources auxquelles elle peut accéder et de contrôler qui peut l'utiliser. Deux cas d'usage principaux justifient cela :

• Single Sign-On (SSO) : permettre aux utilisateurs de se connecter à une application tierce (SaaS, interne) avec leur compte Microsoft, sans créer un mot de passe supplémentaire.
• Accès aux API Microsoft : lire des e-mails via Microsoft Graph, écrire dans SharePoint, envoyer des Teams messages ou interroger Azure AD — tout cela nécessite une application enregistrée avec les bonnes permissions.

App Registration vs Enterprise Application

Lorsque tu enregistres une application dans Entra ID, Microsoft crée en réalité deux objets distincts dans le tenant, que l'on appelle souvent « les deux faces d'une même médaille » :

• App Registration (inscription d'application) : c'est la définition globale de l'application — son Client ID, ses secrets, ses permissions demandées, ses Redirect URIs. Il n'en existe qu'un seul, dans le tenant où l'application a été créée. C'est ici que tu configures et développes l'application.
• Enterprise Application (application d'entreprise) / Service Principal : c'est la représentation locale de l'application dans un tenant spécifique. C'est elle qui stocke les permissions réellement accordées (consentement), les affectations d'utilisateurs, les paramètres SSO. Si ton application est multi-tenant, chaque tenant client a son propre Service Principal.

Enregistrer une application : les étapes essentielles

Pour enregistrer une application dans le portail Azure (ou Entra Admin Center), tu accèdes à Entra ID > App registrations > New registration. Voici les informations clés à configurer :

Client ID et Client Secret

À la création, Entra ID génère automatiquement un Application (client) ID — un GUID unique qui identifie ton application publiquement. C'est l'équivalent d'un nom d'utilisateur.

Pour que l'application puisse s'authentifier, elle a besoin d'un secret. Tu peux créer un Client Secret (une chaîne de caractères aléatoire avec une date d'expiration) ou un certificat (recommandé en production).

# Exemple d'identifiants d'une App Registration
Application (client) ID : a1b2c3d4-e5f6-7890-abcd-ef1234567890
Directory (tenant) ID  : 9z8y7x6w-v5u4-3210-fedc-ba9876543210
Client Secret          : Xq8~AbCdEfGhIjKlMnOpQrStUv.WxYz12345
Expiration             : 2026-05-11 (max 24 mois)

Redirect URI

La Redirect URI (ou Reply URL) est l'URL vers laquelle Entra ID redirige l'utilisateur après une authentification réussie, en transmettant le code d'autorisation. Elle doit correspondre exactement à ce que ton application déclare — c'est une mesure de sécurité critique pour éviter les attaques de type open redirect.

# Exemples de Redirect URIs valides
https://monapp.example.com/auth/callback   # application web en production
http://localhost:3000/auth/callback          # développement local (http autorisé)
https://jwt.ms                               # outil de débogage Microsoft
myapp://auth                                 # application mobile (custom scheme)

Types d'authentification : application vs déléguée

OAuth 2.0 définit plusieurs grant types (flux d'autorisation). Dans Entra ID, deux cas de figure sont fondamentaux :

Authentification d'application (Client Credentials Flow)

L'application s'authentifie en son propre nom, sans utilisateur connecté. Utilisé pour les scripts automatisés, les jobs planifiés, les démons et les services back-end. L'application présente son Client ID et son Client Secret (ou certificat) directement à Entra ID.

# Flux Client Credentials : l'app s'authentifie elle-même
# POST vers : https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token

grant_type    = client_credentials
client_id     = a1b2c3d4-e5f6-7890-abcd-ef1234567890
client_secret = Xq8~AbCdEfGhIjKlMnOpQrStUv.WxYz12345
scope         = https://graph.microsoft.com/.default

# Réponse : un access token valide 1 heure, utilisable pour appeler l'API

Authentification déléguée (Authorization Code Flow)

L'application agit au nom d'un utilisateur connecté. Entra ID demande à l'utilisateur de s'authentifier et de consentir. L'application reçoit un token qui représente cet utilisateur — elle ne peut faire que ce que l'utilisateur est autorisé à faire. C'est le flux standard pour les applications web et les SPA.

# Flux Authorization Code : l'utilisateur se connecte, l'app agit en son nom

# Étape 1 : rediriger l'utilisateur vers Entra ID
GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
  ?client_id=a1b2c3d4-...
  &response_type=code
  &redirect_uri=https://monapp.example.com/auth/callback
  &scope=openid profile email Mail.Read
  &state=xyz123

# Étape 2 : l'utilisateur se connecte et consent
# Entra ID redirige vers : /auth/callback?code=OAQABAAIAAAAm...&state=xyz123

# Étape 3 : l'app échange le code contre des tokens
POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
  grant_type=authorization_code
  &code=OAQABAAIAAAAm...
  &redirect_uri=https://monapp.example.com/auth/callback
  &client_id=a1b2c3d4-...
  &client_secret=Xq8~...

Permissions et scopes

Toutes les applications ne doivent pas accéder à toutes les données. Entra ID utilise un système de permissions granulaires pour contrôler exactement ce à quoi une application a accès.

Permissions déléguées vs permissions d'application

• Permissions déléguées : l'application agit au nom d'un utilisateur connecté. Les droits effectifs sont l'intersection des droits de l'utilisateur et des permissions accordées à l'application. Exemple : Mail.Read permet de lire les e-mails de l'utilisateur connecté.
• Permissions d'application (application permissions) : l'application agit sans utilisateur connecté, avec ses propres droits. Beaucoup plus puissantes — une permission Mail.Read d'application permet de lire les e-mails de tous les utilisateurs du tenant. Nécessitent toujours un consentement administrateur.

Microsoft Graph et les scopes

Microsoft Graph est l'API unifiée de Microsoft 365 — elle expose les données de Teams, Outlook, SharePoint, OneDrive, Azure AD, etc. via une seule URL de base : https://graph.microsoft.com/v1.0/.

Chaque endpoint de Graph est protégé par un ou plusieurs scopes. Tu déclares les scopes dont ton application a besoin dans l'App Registration, sous API permissions.

# Exemples de scopes Microsoft Graph courants
openid              # authentification OIDC (ID token)
profile             # nom, prénom de l'utilisateur
email               # adresse e-mail de l'utilisateur
User.Read           # lire le profil de l'utilisateur connecté
Mail.Read           # lire les e-mails (délégué = boîte de l'user, application = toutes)
Calendars.ReadWrite # lire et modifier les calendriers
Group.Read.All      # lire tous les groupes du tenant
Directory.Read.All  # lire toute la structure d'annuaire — très sensible

Consentement : utilisateur et administrateur

Demander des permissions ne suffit pas — elles doivent être accordées par un consentement. Entra ID distingue deux niveaux de consentement :

Consentement utilisateur

Pour les permissions déléguées peu sensibles (comme User.Read, profile, email), chaque utilisateur peut consentir lui-même la première fois qu'il se connecte à l'application. Une boîte de dialogue s'affiche : « Cette application souhaite accéder à... Acceptez-vous ? ». C'est le comportement par défaut dans Entra ID.

Consentement administrateur

Certaines permissions sont trop sensibles pour être accordées par des utilisateurs ordinaires. Les permissions d'application (sans utilisateur connecté) et de nombreuses permissions déléguées sensibles (Mail.ReadWrite, Group.Read.All, etc.) nécessitent qu'un administrateur du tenant donne son consentement au nom de toute l'organisation.

L'administrateur peut accorder ce consentement depuis le portail Entra ID (Enterprise Applications > Permissions > Grant admin consent) ou en cliquant sur une URL de consentement spéciale :

# URL de consentement administrateur
https://login.microsoftonline.com/{tenant-id}/adminconsent
  ?client_id=a1b2c3d4-e5f6-7890-abcd-ef1234567890
  &redirect_uri=https://monapp.example.com/auth/callback

Politique de consentement

Les administrateurs Entra ID peuvent configurer la politique de consentement utilisateur pour contrôler ce que les utilisateurs sont autorisés à consentir. Trois options courantes :

• Autoriser le consentement utilisateur pour toutes les apps : flexible mais risqué (les utilisateurs peuvent accorder trop de droits).
• Autoriser le consentement uniquement pour les apps vérifiées : compromis raisonnable, recommandé par Microsoft.
• Désactiver le consentement utilisateur : tout passe par l'administrateur, contrôle maximum.

Tokens : access token, refresh token, ID token

À l'issue d'une authentification réussie, Entra ID émet un ou plusieurs tokens JWT (JSON Web Token). Chaque token a un rôle précis :

Access Token

C'est le token que l'application présente à l'API pour prouver qu'elle est autorisée. Il contient les scopes accordés, l'identité de l'utilisateur (ou de l'application), l'audience (quelle API peut l'accepter) et une signature cryptographique. Durée de vie courte : 1 heure par défaut.

Refresh Token

Token opaque (non lisible) que l'application utilise pour obtenir un nouvel access token sans que l'utilisateur ait à se reconnecter. Il est émis uniquement dans les flux avec utilisateur (pas dans Client Credentials). Durée de vie longue : 24 heures à 90 jours selon la configuration.

ID Token

Token propre à OpenID Connect (OIDC) — c'est la couche d'identité au-dessus d'OAuth 2.0. Il prouve l'identité de l'utilisateur connecté et contient des claims comme le nom, l'e-mail, l'Object ID. Il est destiné à l'application, pas aux API. Durée de vie : 1 heure.

# Exemple de claims dans un ID Token décodé (format JSON)
{
  "iss": "https://login.microsoftonline.com/9z8y7x6w-.../v2.0",
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy9821v",
  "aud": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "iat": 1715420000,
  "exp": 1715423600,
  "name": "Thierry Olivier",
  "preferred_username": "thierry@contoso.com",
  "oid": "00000000-0000-0000-abcd-1234567890ab",
  "tid": "9z8y7x6w-v5u4-3210-fedc-ba9876543210"
}

Le claim oid (Object ID) est l'identifiant immuable de l'utilisateur dans le tenant — c'est lui qu'on utilise pour relier un compte Entra ID à un compte dans ta propre base de données. Ne jamais utiliser sub ou email comme identifiant stable.