Configurez l’authentification sans certificat avec Microsoft. Identity.Web

Cet article explique comment configurer l’authentification sans certificat afin que votre application s’authentifie avec Microsoft Entra ID sans gérer les certificats ou les secrets clients. Votre application utilise un FIC (Federated Identity Credential) soutenu par une identité managée Azure pour obtenir des jetons, ce qui élimine la rotation des informations d’identification, réduit la prolifération des secrets et simplifie les déploiements Azure.

Microsoft. Identity.Web prend en charge l’authentification sans certificat via le type de source d’informations d’identification SignedAssertionFromManagedIdentity, disponible dans la version 2.12.0 et ultérieure.

Comprendre l’authentification sans certificat

Cette section explique comment fonctionne l’authentification sans certificat et quand l’utiliser.

Traditionnellement, les applications clientes confidentielles prouvent leur identité à Microsoft Entra ID en présentant une clé secrète client ou un certificat. Les deux approches vous obligent à gérer le cycle de vie des informations d’identification : rotation des secrets avant leur expiration, renouvellement de certificats et stockage sécurisé.

Les informations d’identification d’identité fédérée (FIC) modifient ce modèle. Avec FIC, vous configurez une relation d’approbation entre l’inscription de votre application et une identité managée. Quand votre application doit s’authentifier :

1. Microsoft.Identity.Web demande un jeton à partir du point de terminaison d’identité managée sur l’hôte Azure.
2. La bibliothèque utilise le jeton Managed Identity comme assertion signée pour s’authentifier auprès de Microsoft Entra ID.
3. Microsoft Entra ID valide l’assertion signée par rapport à la configuration des informations d’identification fédérées sur l’inscription de l’application.
4. Microsoft Entra ID émet un jeton d’accès pour la ressource demandée.

Le résultat est un déploiement entièrement sans informations d’identification où aucun secret ou certificat n’existe dans vos variables de configuration, de code ou d’environnement.

Choisir l’approche d’authentification appropriée

Le tableau suivant vous aide à décider quand l’authentification sans certificat est le bon choix.

Prerequisites

Vérifiez que vous disposez des ressources et des outils suivants avant de commencer :

• Un abonnement Azure. Si vous n’en avez pas, créez un compte gratuit.
• Une inscription d’application dans Microsoft Entra ID avec les autorisations d’API requises pour votre scénario.
• Une Identité managée dans Azure, soit attribuée par le système à votre ressource de calcul, soit une identité managée autonome attribuée par l'utilisateur.
• Microsoft. Identity.Web version 2.12.0 ou ultérieure installée dans votre projet.
• Ressource de calcul Azure prenant en charge l’identité managée, telle que Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps ou Machines virtuelles Azure.

Étape 1 : Créer ou identifier une identité managée

Vous pouvez utiliser une Identité Managée assignée par le système ou par l'utilisateur. Si vous n’en avez pas encore créé, suivez les instructions de votre scénario.

Option A : Utiliser une identité managée affectée par le système

Les identités managées affectées par le système sont liées au cycle de vie d’une ressource Azure. Lorsque vous activez une identité affectée par le système sur une ressource comme App Service, Azure crée automatiquement une identité.

1. Dans le portail Azure, accédez à votre ressource de calcul (par exemple, votre App Service).
2. Sélectionnez Identité dans le menu de navigation de gauche.
3. Sous l’onglet Attribuée par le système, définissez État sur Activé.
4. Sélectionnez Enregistrer et confirmer l’action.
5. Une fois l’identité créée, copiez l’ID d’objet (principal). Vous avez besoin de cette valeur lors de la configuration des informations d’identification fédérées.

Option B : Créer une identité gérée assignée à l'utilisateur

Les identités managées affectées par l’utilisateur sont des ressources autonomes Azure que vous pouvez affecter à une ou plusieurs ressources de calcul.

1. Dans le portail Azure, recherchez Identités managées et sélectionnez-la.
2. Cliquez sur Créer.
3. Choisissez votre abonnement, votre groupe de ressources, votre région et entrez un nom pour l’identité.
4. Sélectionnez Vérifier + créer, puis Créer.
5. Une fois le déploiement terminé, ouvrez la nouvelle ressource d’identité managée.
6. Copiez l’ID client à partir de la page Vue d’ensemble . Vous avez besoin de cette valeur pour la configuration de votre application.

Étape 2 : Configurer des informations d’identification d’identité fédérée dans le portail Azure

Un identifiant fédéré établit une relation de confiance entre l'enregistrement de votre application et l'identité managée. Procédez comme suit pour en créer un :

1. Dans le portail Azure, accédez à Microsoft Entra ID>inscriptions d'applications.

2. Sélectionnez l’inscription de l’application utilisée par votre application.

3. Dans le menu de navigation de gauche, sélectionnez Certificats et secrets.

4. Sélectionnez l’onglet Informations d’identification fédérées .

5. Sélectionnez Ajouter des informations d’identification.

6. Dans le scénario d’informations d’identification fédérées, sélectionnez Clés gérées par le client ou Autre émetteur (les options disponibles dépendent de votre version du portail).

7. Configurez les champs suivants :

   Champ	Valeur
   Émetteur	https://login.microsoftonline.com/{tenant-id}/v2.0 : remplacez {tenant-id} par votre ID de locataire Microsoft Entra.
   Identificateur de l’objet	ID d’objet (principal) de l’identité managée. Pour les identités attribuées par le système, recherchez cela sur la page Identité de la ressource. Pour les identités associées à un utilisateur, trouvez cela sur la page Vue d'ensemble de l'identité managée sous l'ID du principal.
   Nom	Nom descriptif, par exemple fic-managed-identity-prod.
   Public ciblé	api://AzureADTokenExchange (valeur par défaut).

8. Cliquez sur Ajouter.

Configurer des informations d’identification d’identité fédérée avec Azure CLI

Vous pouvez également créer les informations d’identification fédérées avec la Azure CLI. La commande suivante crée des informations d’identification sur l’inscription de votre application :

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

URL de l’émetteur par service Azure

L’URL de l’émetteur dans les informations d’identification fédérées dépend du service Azure qui héberge votre application :

Format de l’identificateur de l’objet

Le format de l’identificateur d’objet dépend du type d’identité managée :

Identité managée affectée par le système : utilisez l’ID d’objet (principal) de la page Identité de la ressource. Il s’agit d’une valeur GUID, par exemple a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Identité managée affectée par l’utilisateur : utilisez l’ID principal (également appelé ID d’objet) à partir de la page Vue d’ensemble de la ressource Managed Identity. Il s’agit également d’une valeur GUID.

Étape 3 : Configurer votre application

Mettre à jour appsettings.json

Ajoutez la ClientCredentials section à votre AzureAd configuration. Réglez le SourceType sur SignedAssertionFromManagedIdentity :

Pour l'identité managée assignée par l'utilisateur

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Remplacez les espaces réservés suivants :

Pour l'identité managée attribuée par le système

Lorsque vous utilisez une identité managée affectée par le système, omettez la ManagedIdentityClientId propriété. Microsoft. Identity.Web utilise automatiquement l’identité affectée par le système de l’hôte :

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Inscrire des services dans Program.cs

Aucune modification de code spéciale n’est requise dans votre configuration de démarrage. Les méthodes standard d'inscription de Microsoft.Identity.Web lisent automatiquement la section ClientCredentials.

L’exemple suivant inscrit l’authentification pour une application web qui connecte des utilisateurs et appelle des API en aval :

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

L’exemple suivant inscrit l’authentification pour une API web qui appelle des API en aval :

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

L’exemple suivant enregistre l’authentification pour une application de démon sans interaction utilisateur :

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web détecte le type source SignedAssertionFromManagedIdentity et gère l’échange de jetons de manière transparente.

Comparaison de l'identité managée attribuée par le système et par l'utilisateur

Choisissez le type d’identité managée qui correspond le mieux à votre architecture. Les sections suivantes décrivent les compromis.

Identité gérée par le système

Une identité affectée par le système est créée et supprimée automatiquement avec la ressource Azure auquel elle appartient.

Avantages :

• Aucune ressource distincte à gérer : le cycle de vie des identités correspond à la ressource de calcul.
• Configuration plus simple pour les déploiements à ressources uniques.
• Aucune ManagedIdentityClientId configuration n'est requise.

Considérations :

• Vous ne pouvez pas partager l’identité entre plusieurs ressources.
• Si vous supprimez et recréez la ressource, l’identité change : vous devez mettre à jour les informations d’identification de l’identité fédérée.

Meilleur pour : Déploiements à instance unique où une ressource de calcul est mappée à une inscription d’application.

Identité gérée attribuée par l'utilisateur

Une identité affectée par l’utilisateur est une ressource Azure autonome avec son propre cycle de vie.

Avantages :

• Partagez une identité unique entre plusieurs ressources de calcul (par exemple, plusieurs instances App Service dans différentes régions).
• L’identité persiste indépendamment du cycle de vie des ressources de calcul.
• Précréez et préconfigurez avant de déployer la ressource de calcul.

Considérations :

• Ressource de Azure supplémentaire à gérer.
• Vous devez spécifier ManagedIdentityClientId dans la configuration.

Meilleur pour : Déploiements multi-instances ou multirégions, modèles de déploiement bleu-vert et scénarios où les ressources de calcul sont fréquemment recréées.

Déployer sur des services de calcul Azure

Après avoir configuré votre application, déployez-la sur un service de calcul Azure prenant en charge Managed Identity.

Azure App Service

1. Activez l’identité managée sur votre App Service (voir l’étape 1).

2. Déployez votre application sur App Service à l’aide de votre méthode préférée (Visual Studio, Azure CLI, GitHub Actions).

3. Vérifiez que la AzureAd section de votre configuration déployée correspond aux paramètres de l’étape 3.

4. Si vous utilisez une identité managée affectée par l’utilisateur, affectez-la à App Service :

   az webapp identity assign \
     --resource-group <resource-group> \
     --name <app-service-name> \
     --identities <managed-identity-resource-id>
   

5. Redémarrez App Service pour récupérer l’attribution d’identité.

Azure Kubernetes Service (AKS)

Pour AKS, utilisez l’identité de charge de travail pour associer un compte de service Kubernetes à l’identité managée. Terminez la procédure suivante :

1. Activez la fonctionnalité d’identité de charge de travail sur votre cluster AKS :

   az aks update \
     --resource-group <resource-group> \
     --name <aks-cluster-name> \
     --enable-oidc-issuer \
     --enable-workload-identity
   

2. Créez un compte de service Kubernetes annoté avec l’ID client Managed Identity :

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-app-sa
     namespace: default
     annotations:
       azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"
   

3. Créez des informations d’identification fédérées liant l’émetteur AKS OIDC à l’identité managée.

4. Configurez votre pod pour utiliser le compte de service :

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: default
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: my-app-sa
     containers:
       - name: my-app
         image: <your-container-image>
   

5. Déployez le pod. Le webhook d’identité de charge de travail injecte les variables d’environnement requises pour le point de terminaison de jeton d’identité managée.

Azure Container Apps

1. Créez ou mettez à jour votre application conteneur avec une identité managée :

   az containerapp identity assign \
     --resource-group <resource-group> \
     --name <container-app-name> \
     --user-assigned <managed-identity-resource-id>
   

2. Déployez votre image conteneur avec la configuration appropriée AzureAd .

3. Le point de terminaison du jeton d'identité managée est automatiquement accessible à l'intérieur du conteneur.

Migrer des certificats vers l’authentification sans certificat

Si votre application utilise actuellement l’authentification basée sur des certificats, vous pouvez migrer vers l’authentification sans certificat avec des modifications de configuration minimales.

Effectuer les étapes de migration

1. Créer une identité managée pour votre ressource de calcul Azure (voir Step 1).

2. Ajoutez des informations d’identification d’identité fédérée à votre inscription d’application (voir l’étape 2).

3. Mettez à jour votre configuration pour ajouter les informations d’identification SignedAssertionFromManagedIdentity . Vous pouvez conserver les informations d’identification de certificat existantes comme secours pendant la migration :

   {
     "AzureAd": {
       "Instance": "https://login.microsoftonline.com/",
       "TenantId": "YOUR_TENANT_ID",
       "ClientId": "YOUR_CLIENT_ID",
       "ClientCredentials": [
         {
           "SourceType": "SignedAssertionFromManagedIdentity",
           "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
         },
         {
           "SourceType": "KeyVault",
           "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
           "KeyVaultCertificateName": "your-cert-name"
         }
       ]
     }
   }
   

   Microsoft.Identity.Web essaie les sources de certificats dans l’ordre. Lors de l'exécution sur Azure, le premier identifiant (SignedAssertionFromManagedIdentity) réussit. En cas d’échec (par exemple, pendant le développement local), la bibliothèque utilise à nouveau le certificat.

4. Déployez et validez dans un environnement intermédiaire avant de l’appliquer à la production.

5. Supprimez les informations d’identification du certificat de la configuration après avoir confirmé que l’authentification sans certificat fonctionne en production.

6. Supprimez le certificat d'Azure Key Vault et de l'enregistrement de l'application lorsqu'il n'est plus nécessaire.

Comparer avant et après la configuration

Les exemples suivants montrent le changement de configuration de l'authentification basée sur certificat vers l'authentification sans certificat.

Avant (basé sur un certificat) :

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Après (sans certificat) :

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Résoudre les erreurs courantes

Utilisez les instructions suivantes pour diagnostiquer et résoudre les problèmes liés à l’authentification sans certificat.

AADSTS70021 : aucun enregistrement d’identité fédérée correspondant trouvé

Cause : L’identificateur de l’objet dans les informations d’identification de l’identité fédérée ne correspond pas à l’ID d’objet (principal) de l’identité managée.

Résolution :

1. Dans le portail Azure, accédez à la ressource d'identité gérée et copiez l'ID principal (également appelé ID d'objet) à partir de la page Vue d’ensemble.
2. Accédez à votre inscription d’application Certificats & secretsIdentifiants fédérés.
3. Vérifiez que le champ identificateur du sujet correspond exactement à l'ID du principal.
4. Si les valeurs ne correspondent pas, supprimez les informations d’identification et recréez-les avec l’identificateur d’objet correct.

AADSTS700024 : l’assertion du client n’est pas dans son intervalle de temps valide

Cause : Le jeton d’identité managée utilisé comme assertion signée a expiré ou l’horloge système est asymétrique.

Résolution :

• Vérifiez que l’horloge système sur votre ressource Azure est exacte.
• Redémarrez l’application pour forcer une nouvelle demande de jeton d’identité managée.
• Si vous exécutez un conteneur, vérifiez que l’horloge du conteneur est synchronisée avec l’hôte.

ManagedIdentityException : le point de terminaison d’identité managée n’est pas disponible

Cause : L'application ne peut pas atteindre le service de métadonnées d'instance Azure (IMDS) ou le point de terminaison de jeton d'identité managée.

Résolution :

• Vérifiez que l’application s’exécute sur une ressource de calcul Azure qui prend en charge Managed Identity.
• Vérifiez que l’identité managée est activée et affectée à la ressource de calcul.
• Pour AKS, assurez-vous que le webhook d'identité de charge de travail est en cours d'exécution et que le pod possède l'annotation de compte de service correcte.
• Pour le développement local, cette erreur est attendue. Utilisez une source alternative d’informations d’identification (consultez les étapes de migration).

AADSTS700016 : Application introuvable dans le répertoire

Cause : La ClientId configuration ne correspond pas à une inscription d’application valide du locataire spécifié.

Résolution :

• Vérifiez que le ClientId correspond à l’ID d'application (client) de l'enregistrement de votre application.
• Vérifiez que le TenantId tenant correspond à l’emplacement où l’application est enregistrée.

Activer la journalisation du débogage

Cause : L’ordre source des informations d’identification ou l’incompatibilité de configuration peut entraîner la bibliothèque à ignorer les informations d’identification FIC.

Résolution :

1. Activez la journalisation dans Microsoft. Identity.Web pour voir les étapes détaillées d’acquisition de jetons. Le code suivant configure la journalisation au niveau du débogage pour les bibliothèques d’identités :

   builder.Services.AddLogging(logging =>
   {
       logging.AddConsole();
       logging.SetMinimumLevel(LogLevel.Debug);
       logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
   });
   

2. Examinez les logs concernant la source de justificatifs d'identité tentée par la bibliothèque et toutes les erreurs renvoyées.

Identité managée affectée par l'utilisateur non prise en compte

Cause : Lorsque plusieurs identités managées affectées par l’utilisateur sont affectées à une ressource de calcul, la bibliothèque peut utiliser la valeur incorrecte si ManagedIdentityClientId elle n’est pas spécifiée.

Résolution :

• Spécifiez toujours la ManagedIdentityClientId propriété lorsque vous utilisez une identité managée affectée par l’utilisateur.
• Vérifiez que l’ID client correspond à l’identité pour laquelle vous avez configuré les informations d’identification de l’identité fédérée.

Passer en revue les avantages de sécurité

L’authentification sans certificat avec FIC offre des avantages de sécurité significatifs par rapport aux approches traditionnelles basées sur les informations d’identification :

Aucun secret de fuite

Étant donné qu’aucun fichier de certificat, mot de passe PFX ou secrets client n’existe dans vos artefacts de configuration ou de déploiement, il n’y a rien à extraire pour un attaquant. Même si un attaquant obtient un accès en lecture à vos fichiers de configuration, il ne peut pas emprunter l'identité de votre application en dehors de Azure.

Aucune rotation des informations d’identification

Les jetons d’identité managée sont de courte durée et sont automatiquement actualisés par la plateforme Azure. Vous n’avez pas besoin d’implémenter des planifications de rotation, de surveiller les dates d’expiration ou de coordonner les mises à jour des informations d’identification entre les déploiements.

Surface d’attaque réduite

Le point de terminaison du jeton d’identité managée est accessible uniquement à partir de la ressource Azure spécifique sur laquelle l’identité est attribuée. Un attaquant ne peut pas utiliser les informations d’identification d’un autre hôte, réseau ou environnement cloud.

Simplification de la conformité

Sans informations d’identification de longue durée, vous éliminez plusieurs catégories de problèmes de conformité :

• Aucun secret stocké dans le contrôle de code source, les variables d’environnement ou les fichiers de configuration.
• Aucun élément clé à auditer, renouveler ou révoquer.
• Aucune infrastructure de certificat (autorité de certification, processus de renouvellement) à gérer.

Défense en profondeur

Combinez l’authentification sans certificat avec d’autres fonctionnalités de sécurité Azure pour la protection en couches :

• Azure RBAC : contrôler les identités qui peuvent accéder aux ressources.
• Accès conditionnel : appliquez des stratégies en fonction du risque d’identité, de l’emplacement et de l’état de l’appareil.
• Points de terminaison privés : Restreindre l’accès réseau aux ressources Azure.
• Microsoft Defender for Cloud : surveillez les modèles d’authentification suspects.

Contenu connexe

• Vue d’ensemble des informations d’identification
• Certificats
• Clés secrètes client
• documentation Identités managées d'Azure
• Documentation sur les informations d’identification de l’identité fédérée
• Dépôt GitHub Microsoft.Identity.Web