Partager via


Sécuriser vos API utilisées en tant que connecteur d’API dans des flux d’utilisateur d’inscription en libre-service de Microsoft Entra External ID

S’applique à :Cercle vert avec un symbole de coche blanche. Locataires de main-d’œuvre Cercle blanc avec un symbole X gris. Locataires externes (en savoir plus)

Lors de l’intégration d’une API REST dans un flux d’utilisateur d’inscription en libre-service de Microsoft Entra External ID, vous devez protéger votre point de terminaison d’API REST en recourant à l’authentification. L’authentification par API REST garantit que seuls les services disposant des informations d’identification appropriées, comme Microsoft Entra ID, peuvent appeler votre point de terminaison. Cet article explique comment sécuriser une API REST.

Prérequis

Suivez les étapes décrites dans le guide Procédure pas à pas : Ajouter un connecteur d'API à un flux d'utilisateurs d'inscription.

Vous pouvez protéger votre point de terminaison d’API à l’aide de l’authentification de base HTTP ou de l’authentification par certificat client HTTPS. Dans les deux cas, vous fournissez les informations d’identification que Microsoft Entra ID utilise lors de l’appel de votre point de terminaison d’API. Votre point de terminaison d'API vérifie ensuite les informations d'identification et prend les décisions relatives aux autorisations.

Authentification HTTP de base

Conseil

Les étapes décrites dans cet article pourraient varier légèrement en fonction du portail de départ.

L’authentification de base HTTP est définie dans le document RFC 2617. L’authentification de base fonctionne comme suit : Microsoft Entra ID envoie une requête HTTP avec les informations d’identification du client (username et password) dans l’en-tête Authorization. Les informations d'identification sont mises en forme en tant que chaîne username:password codée en base64. Votre API est ensuite chargée de vérifier ces valeurs pour prendre d’autres décisions d’autorisation.

Pour configurer un connecteur d'API avec l'authentification de base HTTP, procédez comme suit :

  1. Connectez-vous au Centre d’administration de Microsoft Entra en tant qu’Administrateur de l’utilisateur.
  2. Accédez à Identité>Identités externes>Vue d’ensemble.
  3. Sélectionnez Tous les connecteurs d’API, puis le Connecteur d’API que vous souhaitez configurer.
  4. Dans le champ Type d'authentification, sélectionnez De base.
  5. Entrez le Nom d'utilisateur et le Mot de passe de votre point de terminaison d'API REST. Capture d’écran de la configuration de l’authentification de base pour un connecteur d’API.
  6. Sélectionnez Enregistrer.

Authentification par certificat client HTTPS

L’authentification par certificat client est une authentification mutuelle basée sur un certificat dans laquelle le client, Microsoft Entra ID, fournit son certificat client au serveur pour prouver son identité. Cela se produit dans le cadre de la négociation SSL. Votre API est chargée de valider les certificats appartenant à un client valide, par exemple Microsoft Entra ID, et de prendre des décisions d’autorisation. Le certificat client est un certificat numérique X.509.

Important

Dans les environnements de production, le certificat doit être signé par une autorité de certification.

Créer un certificat

Pour créer un certificat, vous pouvez utiliser Azure Key Vault, qui propose des options pour les certificats auto-signés et des intégrations auprès de fournisseurs d'émetteurs de certificats pour les certificats signés. Paramètres recommandés :

  • Objet : CN=<yourapiname>.<tenantname>.onmicrosoft.com
  • Type de contenu : PKCS #12
  • Type d'action de la durée de vie : Email all contacts at a given percentage lifetime ou Email all contacts a given number of days before expiry
  • Type de clé : RSA
  • Taille de la clé : 2048
  • Clé privée exportable : Yes (afin de pouvoir exporter un fichier .pfx)

Vous pouvez ensuite exporter le certificat.

Option 2 : préparer un certificat auto-signé à l’aide de PowerShell

Si vous n’avez pas encore de certificat, vous pouvez utiliser un certificat auto-signé. Un certificat auto-signé est un certificat de sécurité qui n’est pas signé par une autorité de certification et qui n’offre pas les garanties de sécurité d’un certificat signé par une autorité de certification.

Sur Windows, utilisez l’applet de commande New-SelfSignedCertificate dans PowerShell pour générer un certificat.

  1. Exécutez la commande PowerShell suivante pour générer un certificat auto-signé. Modifiez l’argument -Subject comme il convient pour votre application et le nom de locataire Azure AD B2C, comme contosowebapp.contoso.onmicrosoft.com. Vous pouvez également ajuster la date de -NotAfter pour spécifier un délai d’expiration différent pour le certificat.

    New-SelfSignedCertificate `
        -KeyExportPolicy Exportable `
        -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
        -KeyAlgorithm RSA `
        -KeyLength 2048 `
        -KeyUsage DigitalSignature `
        -NotAfter (Get-Date).AddMonths(12) `
        -CertStoreLocation "Cert:\CurrentUser\My"
    
  2. Sur un ordinateur Windows, recherchez et sélectionnez Gérer les certificats utilisateur

  3. Sous Certificats - Utilisateur actuel, sélectionnez Personnel>Certificats>votrenomdappli.votrelocataire.onmicrosoft.com.

  4. Choisissez le certificat, puis sélectionnez Action>Toutes les tâches>Exporter.

  5. Sélectionnez Suivant>Oui, exporter la clé privée>Suivant.

  6. Acceptez les valeurs par défaut pour Format de fichier d’exportation, puis sélectionnez Suivant.

  7. Activez l’option Mot de passe, entrez un mot de passe pour le certificat, puis sélectionnez Suivant.

  8. Pour spécifier un emplacement d’enregistrement de votre certificat, sélectionnez Parcourir et accédez à un répertoire de votre choix.

  9. Dans la fenêtre Enregistrer sous, entrez un Nom de fichier, puis sélectionnez Enregistrer.

  10. Sélectionnez Suivant>Terminer.

Pour qu’Azure AD B2C accepte le mot de passe du fichier .pfx, celui-ci doit être chiffré à l’aide de l’option TripleDES-SHA1 de l’utilitaire d’exportation du magasin de certificats Windows, par opposition à AES256-SHA256.

Configurer votre connecteur d'API

Pour configurer un connecteur d'API avec l'authentification par certificat client, procédez comme suit :

  1. Connectez-vous au Centre d’administration de Microsoft Entra en tant qu’Administrateur de l’utilisateur.
  2. Accédez à Identité>Identités externes>Vue d’ensemble.
  3. Sélectionnez Tous les connecteurs d’API, puis le Connecteur d’API que vous souhaitez configurer.
  4. Dans le champ Type d'authentification, sélectionnez Certificat.
  5. Dans la zone Charger le certificat, sélectionnez le fichier .pfx de votre certificat avec une clé privée.
  6. Dans la zone Entrer le mot de passe, saisissez le mot de passe du certificat. Capture d’écran de la configuration de l’authentification par certificat pour un connecteur d’API.
  7. Sélectionnez Enregistrer.

Prendre des décisions d’autorisation

Votre API doit implémenter l'autorisation basée sur les certificats clients envoyés afin de protéger les points de terminaison d'API. Pour Azure App Service et Azure Functions, consultez Configurer l'authentification mutuelle TLS afin de savoir comment activer et valider le certificat à partir de votre code d'API. Vous pouvez également utiliser la gestion des API Azure en tant que couche devant un service API pour vérifier les propriétés de certificat client par rapport aux valeurs souhaitées.

Renouvellement de certificats

Nous vous recommandons de définir des alertes de rappel avant la date d’expiration de votre certificat. Vous devez générer un nouveau certificat et répéter les étapes ci-dessus lorsque les certificats utilisés sont sur le point d’expirer. Pour « roder » l’utilisation d’un nouveau certificat, votre service d’API peut continuer à accepter les anciens et nouveaux certificats pendant un laps de temps limité pendant le déploiement du nouveau certificat.

Pour charger un nouveau certificat sur un connecteur d’API existant, sélectionnez le connecteur d'API sous Connecteurs d’API, puis sélectionnez Charger un nouveau certificat. Le dernier certificat chargé qui n’a pas expiré, et dont la date de début est dépassée, sera automatiquement utilisé par Microsoft Entra ID.

Capture d’écran d’un nouveau certificat, lorsqu’il en existe déjà un.

Authentification par clé API

Certains services utilisent un mécanisme de « clé API » pour obfusquer l’accès à vos points de terminaison HTTP pendant le développement en obligeant l’appelant à inclure une clé unique comme un en-tête HTTP ou un paramètre de requête HTTP. Pour Azure Functions, vous pouvez effectuer cette opération en incluant code comme paramètre de requête dans l’URL du point de terminaison de votre connecteur d’API. Par exemple, https://contoso.azurewebsites.net/api/endpoint?code=0123456789).

Ce mécanisme ne doit pas être utilisé seul en production. Par conséquent, la configuration de l'authentification de base ou par certificat est toujours requise. Si vous ne souhaitez implémenter aucune méthode d’authentification (non recommandé) à des fins de développement, vous pouvez choisir l’authentification « de base » dans la configuration du connecteur d’API et utiliser des valeurs temporaires pour username et password, que votre API peut ignorer pendant que vous implémentez l’autorisation adéquate.

Étapes suivantes