Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’APPLIQUE À : tous les niveaux de Gestion des API
Important
À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.
Ce scénario montre comment configurer votre instance de Gestion des API Azure pour protéger une API. Nous utilisons le flux SPA Azure AD B2C (Auth Code + PKCE) pour acquérir un jeton, en même temps que Gestion des API pour sécuriser un back-end Azure Functions à l’aide de EasyAuth.
Pour obtenir une vue d’ensemble conceptuelle de l’autorisation des API, consultez Authentification et autorisation aux API dans le service Gestion des API.
Objectifs
Nous allons voir comment le service Gestion des API peut être utilisé dans un scénario simplifié avec Azure Functions et Azure AD B2C. Vous allez créer une application JavaScript (JS) appelant une API, qui connecte les utilisateurs avec Azure AD B2C. Vous utiliserez ensuite les fonctionnalités de stratégie validate-jwt, CORS et Limitation du débit par clé de la Gestion des API pour protéger l’API back-end.
Pour une défense en profondeur, vous aurez ensuite recours à EasyAuth pour valider à nouveau le jeton à l’intérieur de l’API back-end et faire en sorte que la Gestion des API soit le seul service qui puisse appeler le back-end Azure Functions.
Ce que vous allez apprendre
- Configuration d’une application monopage et d’une API back-end dans Azure Active Directory B2C
- Création d’une API back-end Azure Functions
- Importation d’une API Azure Functions dans la Gestion des API Azure
- Sécurisation de l’API dans la Gestion des API Azure
- Appel des points de terminaison d'autorisation Azure Active Directory B2C via les bibliothèques de la plateforme d'identité Microsoft (MSAL.js)
- Stockage d’une application monopage JS HTML/Vanilla et traitement de celle-ci à partir d’un point de terminaison de Stockage Blob Azure
Prérequis
Pour suivre les étapes décrites dans cet article, vous devez avoir :
- Un compte de stockage universel v2 (StorageV2) Azure pour héberger l’application monopage JS front-end
- Une instance Gestion des API Azure (n’importe quel niveau fonctionne, y compris « Consommation », mais certaines fonctionnalités applicables au scénario complet ne sont pas disponibles dans ce niveau (limite de débit par clé et adresse IP virtuelle dédiée), ces restrictions sont décrites ci-dessous dans l’article le cas échéant.
- Une application de fonction Azure vide (exécutant le runtime .NET Core v3.1, sur un plan Consommation) pour héberger l’API appelée
- Un locataire Azure AD B2C lié à un abonnement
Bien qu'en pratique, vous utilisiez des ressources dans la même région pour des charges de travail en production, dans ce tutoriel, la région du déploiement n’a pas d’importance.
Vue d’ensemble
Voici une illustration des composants utilisés et du flux qui les relie une fois ce processus terminé.
Voici un petit aperçu de la procédure :
Créer les composants Azure AD B2C appelants (front-end, Gestion des API) et les applications API avec des étendues, et accorder l’accès à l’API
Créer les stratégies d’inscription et de connexion pour permettre aux utilisateurs de se connecter avec Azure AD B2C
Configurer Gestion des API avec les nouveaux ID clients et clés Azure AD B2C pour activer l’autorisation utilisateur OAuth2 dans la console de développement
Générer l’API de fonction
Configurer l’API de fonction pour activer EasyAuth avec les nouveaux ID clients et clés Azure AD B2C, et verrouiller sur l’adresse IP virtuelle APIM
Générer la définition d’API dans Gestion des API
Configurer OAuth2 pour la configuration de l’API Gestion des API
Configurer la stratégie CORS et ajouter une stratégie validate-jwt afin de valider le jeton OAuth pour chaque requête entrante
Générer l’application appelante pour consommer l’API
Charger l’exemple d’application monopage JS
Configurer l’exemple d’application cliente JS avec les nouveaux ID clients et clés Azure AD B2C
Tester l’application cliente
Conseil
Nous allons recueillir plusieurs informations et clés, etc., au fil de la lecture de ce document. Vous trouverez peut-être utile d’ouvrir un éditeur de texte pour stocker temporairement les éléments de configuration suivants.
ID CLIENT PRINCIPAL B2C : CLÉ SECRÈTE CLIENT PRINCIPAL B2C : URI DE L’ÉTENDUE DE L’API BACK-END B2C : ID CLIENT FRONTEND B2C : URI DU POINT DE TERMINAISON DE FLUX UTILISATEUR B2C : POINT DE TERMINAISON OPENID B2C CONNU : NOM DE LA STRATÉGIE B2C : Frontendapp_signupandsignin URL DE LA FONCTION : URL DE BASE DE L’API APIM : URL DU POINT DE TERMINAISON PRINCIPAL DU STOCKAGE :
Configuration de l’application back-end
Ouvrez le panneau Azure AD B2C dans le portail et effectuez les étapes ci-dessous.
Sélectionnez l’onglet Inscriptions d’applications.
Sélectionnez le bouton « Nouvelle inscription ».
Choisissez « Web » dans la zone de sélection de l’URI de redirection.
Maintenant, définissez le Nom d’affichage : choisissez un nom unique correspondant au service créé. Dans cet exemple, nous allons utiliser le nom « Application principale ».
Utilisez des espaces réservés pour les URL de réponse, par exemple « https://jwt.ms » (un site de décodage de jetons appartenant à Microsoft). Nous mettrons à jour ces URL ultérieurement.
Veillez à sélectionner l’option « Comptes de n’importe quel fournisseur d’identité ou annuaire organisationnel (pour authentifier les utilisateurs avec des flux d’utilisateur) ».
Dans le cadre de cet exemple, décochez la case « Accorder le consentement administrateur », car nous n’aurons pas besoin des autorisations offline_access.
Sélectionnez « Inscrire ».
Enregistrez l’ID client de l’application back-end, indiqué sous « ID (client) de l’application », pour plus tard.
Sélectionnez l’onglet Certificats et secrets (sous Gérer), puis sélectionnez « Nouveau secret client » pour générer une clé d’authentification (acceptez les paramètres par défaut et sélectionnez « Ajouter »).
Lorsque vous cliquez sur « Ajouter », copiez la clé (sous « valeur ») quelque part en toute sécurité pour une utilisation ultérieure comme « Secret client principal ». Notez que cette boîte de dialogue est la seule chance que vous devrez copier cette clé.
Sélectionnez maintenant l’onglet Exposer une API (sous Gérer).
Vous serez invité à définir l’URI AppID, à sélectionner et à enregistrer la valeur par défaut.
Créez et nommez l’étendue « Hello » pour votre API de fonction, vous pouvez utiliser l’expression « Hello » pour toutes les options entréeables, enregistrant l’URI de valeur d’étendue complète renseignée, puis sélectionnez « Ajouter une étendue ».
Revenez à la racine du panneau Azure AD B2C en sélectionnant « Azure AD B2C » dans la barre de navigation en haut à gauche du portail.
Notes
Les étendues Azure AD B2C sont en fait des autorisations au sein de votre API auxquelles d’autres applications peuvent demander l’accès par le biais du panneau d’accès d’API à partir de leurs applications. Concrètement, vous venez de créer des autorisations d’application pour votre API appelée.
Configuration de l’application front-end
- Sélectionnez l’onglet Inscriptions d’applications.
- Sélectionnez le bouton « Nouvelle inscription ».
- Choisissez « Application monopage (SPA) » dans la zone de sélection de l’URI de redirection.
- Définissez maintenant le Nom d’affichage et l’URI AppID : choisissez un nom unique et pertinent pour l’application front-end qui utilisera cette inscription d’application Azure Active Directory B2C. Dans cet exemple, vous pouvez utiliser « Application front-end ».
- Comme pour la première inscription d’application, laissez la sélection par défaut des types de comptes pris en charge (authentification des utilisateurs avec des flux d’utilisateurs).
- Utilisez des espaces réservés pour les URL de réponse, par exemple « https://jwt.ms » (un site de décodage de jetons appartenant à Microsoft). Nous mettrons à jour ces URL ultérieurement.
- Laissez la case Accorder le consentement Administrateur cochée.
- Sélectionnez « Inscrire ».
- Enregistrez l’ID client de l’application front-end, indiqué sous « ID (client) de l’application », pour plus tard.
- Basculer sur l’onglet Autorisations de l’API.
- Accordez l’accès à l’application back-end en cliquant sur « Ajouter une autorisation », puis sur « Mes API », sélectionnez « Application principale », sélectionnez « Autorisations », sélectionnez l’étendue que vous avez créée dans la section précédente, puis sélectionnez « Ajouter des autorisations ».
- Sélectionnez « Accorder le consentement administrateur pour {tenant} et sélectionnez « Oui » dans la boîte de dialogue contextuelle. Cette fenêtre contextuelle autorise l’« Application front-end » à utiliser l’autorisation « Hello » définie dans l’« Application back-end » créée précédemment.
- Toutes les autorisations devraient maintenant s’afficher pour l’application sous la forme d’une coche verte dans la colonne État.
Créer un flux d’utilisateur « Inscription et connexion »
Revenez à la racine du panneau B2C en sélectionnant Azure AD B2C dans la barre de navigation.
Basculez vers l’onglet « Flux d’utilisateurs » (sous Stratégies).
Sélectionnez « Nouveau flux utilisateur »
Choisissez le type de flux d’utilisateur « Inscription et connexion », sélectionnez « Recommandé », puis « Créer ».
Donnez un nom à la stratégie et prenez-en note pour une utilisation ultérieure. Pour cet exemple, vous pouvez utiliser « Frontendapp_signupandsignin », notez que cela sera précédé de « B2C_1_ » pour créer « B2C_1_Frontendapp_signupandsignin »
Sous « Fournisseurs d’identité » et « Comptes locaux », cochez « Inscription par e-mail » (ou « Inscription à l’ID utilisateur » en fonction de la configuration de votre locataire B2C), puis sélectionnez OK. Cette configuration est due au fait que nous allons inscrire des comptes B2C locaux, et non pas nous en remettre à un autre fournisseur d’identité (par exemple un fournisseur d’identité sociale) pour utiliser le compte de réseau social existant d’un utilisateur.
Laissez les paramètres par défaut pour l’authentification MFA et l’accès conditionnel.
Sous « Attributs utilisateur et revendications », sélectionnez « Afficher plus... » choisissez ensuite les options de revendication que vous souhaitez que vos utilisateurs entrent et aient retournées dans le jeton. Vérifiez au moins « Nom d’affichage » et « Adresse e-mail » pour collecter, avec « Nom d’affichage » et « Adresses e-mail » à renvoyer (faites attention au fait que vous collectez l’adresse e-mail, au singulier, et demandez à renvoyer des adresses e-mail, multiples), puis sélectionnez « OK », puis sélectionnez « Créer ».
Sélectionnez le flux utilisateur que vous avez créé dans la liste, puis sélectionnez le bouton « Exécuter le flux utilisateur ».
Cette action ouvre le panneau Exécuter le flux utilisateur, sélectionnez l’application frontale, copiez le point de terminaison de flux utilisateur et enregistrez-le ultérieurement.
Copiez et stockez le lien situé en haut, en l’enregistrant comme « Point de terminaison de configuration OpenID reconnu » pour plus tard.
Notes
Les stratégies B2C vous permettent d’exposer les points de terminaison de connexion Azure AD B2C pour pouvoir capturer différents composants de données et connecter des utilisateurs de différentes manières.
Dans ce cas, nous avons configuré un flux d’inscription ou de connexion (stratégie). A également été exposé un point de terminaison de configuration reconnu. Dans les deux cas, notre stratégie créée a été identifiée dans l’URL par le paramètre de chaîne de requête « p = ».
Vous disposez au bout du compte d’une Plateforme d’identités entreprise-client fonctionnelle qui connecte les utilisateurs à plusieurs applications.
Générer l’API de fonction
Revenez à votre locataire Microsoft Entra standard dans le portail Azure afin que nous puissions à nouveau configurer les éléments de votre abonnement.
Accédez au panneau Function Apps du portail Azure, ouvrez votre application de fonction vide, puis sélectionnez « Fonctions », sélectionnez « Ajouter ».
Dans le menu volant qui s’affiche, choisissez « Développer dans le portail », sous « Sélectionner un modèle », puis choisissez « Déclencheur HTTP », sous Nom de modèle « hello » avec le niveau d’autorisation « Function », puis sélectionnez Ajouter.
Basculez vers le panneau Code + test, puis copiez-collez l’exemple de code ci-dessous sur le code existant qui s’affiche.
Sélectionnez Enregistrer.
using System.Net; using Microsoft.AspNetCore.Mvc; using Microsoft.Extensions.Primitives; public static async Task<IActionResult> Run(HttpRequest req, ILogger log) { log.LogInformation("C# HTTP trigger function processed a request."); return (ActionResult)new OkObjectResult($"Hello World, time and date are {DateTime.Now.ToString()}"); }Conseil
Le code de fonction de script C# que vous venez de coller enregistre simplement une ligne dans les journaux de fonctions et retourne le texte « Hello World » avec des données dynamiques (date et heure).
Sélectionnez « Intégration » dans le panneau de gauche, puis sélectionnez le lien http (req) dans la zone « Déclencheur ».
Dans la liste déroulante « Méthodes HTTP sélectionnées », décochez la méthode HTTP POST, en laissant uniquement GET sélectionnée, puis sélectionnez Enregistrer.
Revenez à l’onglet Code + Test, sélectionnez « Obtenir l’URL de la fonction », puis copiez l’URL qui s’affiche et enregistrez-la ultérieurement.
Notes
Les liaisons que vous venez de créer imposent simplement à Functions de répondre aux requêtes HTTP GET anonymes envoyées à l’URL copiée (
https://yourfunctionappname.azurewebsites.net/api/hello?code=secretkey). Nous disposons maintenant d’une API https serverless évolutive capable de retourner une charge utile simple.Vous pouvez à présent tester l’appel de cette API à partir d’un navigateur web en utilisant votre version de l’URL ci-dessus, que vous venez de copier et d’enregistrer. Vous pouvez également supprimer la partie des paramètres de chaîne de requête « ?code=secretkey » de l’URL, puis tester à nouveau, pour prouver qu’Azure Functions renvoie une erreur 401.
Configurer et sécuriser l’API de fonction
Deux zones supplémentaires de l’application de fonction doivent être configurées (Autorisation et Restrictions de réseau).
Nous allons d’abord configurer Authentification/autorisation. Revenez au panneau racine de l’application de fonction grâce à la barre de navigation.
Sélectionnez maintenant « Authentification » (sous « Paramètres »).
Sélectionnez « Ajouter un fournisseur d’identité »
Sélectionnez « Microsoft » dans la liste déroulante de fournisseurs d’identité
Pour l’inscription d’application, sélectionnez « Fournir les détails d’une inscription d’application existante »
Collez l’ID client de l’application back-end (à partir d’Azure AD B2C) dans la zone « ID d’application (client) » (nous avons enregistré cette configuration précédemment).
Collez le point de terminaison de configuration open-id bien connu de la stratégie d’inscription et de connexion vers la zone URL de l’émetteur (nous avons précédemment enregistré cette configuration).
Collez la clé secrète client de l’application back-end dans la zone appropriée (nous avons enregistré cette configuration précédemment).
Pour « Requêtes non authentifiées », sélectionnez « HTTP 401 Non autorisé : recommandé pour les API »
Laissez Magasin de jetons activé (par défaut).
Sélectionnez « Enregistrer » (en haut à gauche du panneau).
Important
Votre API Function est maintenant déployée et devrait retourner des réponses 401 si le jeton JWT fourni comme en-tête Authorization: Bearer n’est pas le bon, et des données quand une requête valide est présentée. Vous avez ajouté une sécurité de défense en profondeur supplémentaire dans EasyAuth en configurant l'option « Connexion avec Microsoft Entra ID » pour gérer les demandes non authentifiées.
Aucune sécurité IP n’est encore appliquée ; si on dispose d’une clé et d’un jeton OAuth2 valides, tout le monde peut appeler cette API depuis n’importe où. Dans l’idéal, nous souhaitons forcer toutes les requêtes à venir par le biais de Gestion des API.
Si vous utilisez les niveaux Consommation de gestion des API, De base v2, Standard v2 et Premium v2, il n’existe pas d’adresse IP virtuelle de gestion des API Azure dédiée pour autoriser la liste avec les restrictions d’accès aux fonctions. Dans les niveaux d’Azure API Management classiques (dédiés), le VIP est à locataire unique et pour la durée de vie de la ressource. Pour les niveaux qui s’exécutent sur une infrastructure partagée, vous pouvez verrouiller vos appels d’API par le biais de la clé de fonction du secret partagé dans la partie de l’URI que vous avez copiée ci-dessus. En outre, pour ces niveaux , les étapes 12-17 ci-dessous ne s’appliquent pas.
Fermez le panneau « Authentification » à partir du portail App Service/Functions.
Ouvrez le panneau Gestion des API du portail, puis votre instance.
Enregistrez l’adresse IP virtuelle privée indiquée dans l’onglet Vue d’ensemble.
Revenez au panneau Azure Functions du portail, puis rouvrez votre instance.
Sélectionnez « Mise en réseau », puis « Configurer les restrictions d’accès ».
Sélectionnez « Ajouter une règle », puis entrez le VIP copié à l’étape 3 ci-dessus au format xx.xx.xx.xx/32.
Si vous souhaitez continuer à interagir avec le portail Functions et effectuer les étapes facultatives ci-dessous, vous devez également ajouter ici votre propre plage CIDR ou adresse IP publique.
Une fois que la liste contient une entrée d’autorisation, Azure ajoute une règle de refus implicite afin de bloquer toutes les autres adresses.
Vous devez ajouter des blocs d’adresses mis en forme CIDR au panneau restrictions IP. Quand vous devez ajouter une adresse unique telle que l’adresse IP virtuelle de Gestion des API, vous devez l’ajouter au format xx.xx.xx.xx/32.
Notes
Désormais, votre API de fonction ne devrait pas pouvoir être appelée depuis un autre endroit qu'à travers la gestion des API ou votre adresse.
Ouvrez le panneau Gestion des API, puis ouvrez votre instance.
Sélectionnez le panneau API (sous API).
Dans le volet « Ajouter une nouvelle API », choisissez « Function App », puis « Complète » dans la partie supérieure de la fenêtre contextuelle.
Cliquez sur Parcourir, choisissez l’application de fonction dans laquelle vous hébergez l’API, puis cliquez sur Sélectionner. Ensuite, cliquez à nouveau sur Sélectionner.
Donnez un nom et une description à l’API pour l’utilisation interne de Gestion des API, et ajoutez-la au produit « unlimited ».
Copiez et enregistrez l’URL de base de l’API, puis sélectionnez « créer ».
Sélectionnez l’onglet « paramètres », puis, sous abonnement, désactivez la case « Abonnement requis », car nous allons utiliser le JWT OAuth dans ce cas pour limiter le débit. Notez que, si vous utilisez le niveau Consommation, cela resterait nécessaire dans un environnement de production.
Conseil
Si vous utilisez le niveau Consommation APIM, le produit Illimité ne sera pas disponible d’emblée. Au lieu de cela, accédez à « Produits » sous « API » et appuyez sur « Ajouter ». Tapez « Illimité » comme nom et description du produit, puis sélectionnez l’API que vous venez d’ajouter à partir de la légende des API « + » en bas à gauche de l’écran. Cochez la case « Publié ». Conservez les autres valeurs par défaut. Enfin, appuyez sur le bouton « Créer ». Le produit « Illimité » a été créé et affecté à votre API. Vous pourrez le personnaliser plus tard.
Configuration et capture des bons paramètres de point de terminaison de stockage
Ouvrez le panneau des comptes de stockage dans le portail Azure.
Sélectionnez le compte que vous avez créé et sélectionnez le panneau « Site web statique » dans la section Paramètres (si aucune option « Site web statique » n’est visible, vérifiez que vous avez créé un compte V2).
Définissez la fonctionnalité d’hébergement web statique sur « activé », puis définissez le nom du document d’index sur «index.html», puis sélectionnez « Enregistrer ».
Notez le contenu du « Point de terminaison principal » pour plus tard, car il s’agit de l’emplacement où le site front-end sera hébergé.
Conseil
Vous pouvez utiliser Stockage Blob Azure + la réécriture CDN ou bien Azure App Service pour héberger l’application SPA. Cependant, la fonctionnalité d’hébergement de site web statique du Stockage Blob fournit un conteneur par défaut pour traiter le contenu web statique/HTML/JS/CSS à partir du Stockage Azure et produit automatiquement une page par défaut.
Configurer les stratégies CORS et validate-jwt
Les instructions des sections suivantes doivent être suivies quel que soit le niveau APIM utilisé. L’URL du compte de stockage provient du compte de stockage que vous aurez mis à disposition dans la partie des prérequis en haut de cet article.
Basculez vers le panneau Gestion des API du portail, puis ouvrez votre instance.
Sélectionnez LES API, puis sélectionnez « Toutes les API ».
Sous « Traitement entrant », sélectionnez le bouton d’affichage du code «< /> » pour afficher l’éditeur de stratégie.
Modifiez la section entrante et collez le code XML ci-dessous pour qu’il ressemble à ce qui suit.
Remplacez les paramètres suivants dans la stratégie :
{PrimaryStorageEndpoint} (« Point de terminaison de stockage principal » copié dans la section précédente), {b2cpolicy-well-known-openid} (« Point de terminaison de configuration OpenID reconnu » copié précédemment) et {backend-api-application-client-id} (application B2C/ID client de l’API back-end) par les valeurs correctes enregistrées précédemment.
Si vous utilisez le niveau Consommation de la Gestion des API, supprimez la stratégie de limitation du débit par clé, car elle n’est pas disponible avec ce niveau.
<inbound> <cors allow-credentials="true"> <allowed-origins> <origin>{PrimaryStorageEndpoint}</origin> </allowed-origins> <allowed-methods preflight-result-max-age="120"> <method>GET</method> </allowed-methods> <allowed-headers> <header>*</header> </allowed-headers> <expose-headers> <header>*</header> </expose-headers> </cors> <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid." require-expiration-time="true" require-signed-tokens="true" clock-skew="300"> <openid-config url="{b2cpolicy-well-known-openid}" /> <required-claims> <claim name="aud"> <value>{backend-api-application-client-id}</value> </claim> </required-claims> </validate-jwt> <rate-limit-by-key calls="300" renewal-period="120" counter-key="@(context.Request.IpAddress)" /> <rate-limit-by-key calls="15" renewal-period="60" counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" /> </inbound>Notes
À présent, la gestion des API Azure est en mesure de répondre aux demandes d’origine croisée de vos applications SPA JavaScript, et elle effectue une limitation, une limitation de débit et une prévalidation du jeton d’authentification JWT transmis AVANT de transférer la requête à l’API de fonction.
Félicitations, vous disposez maintenant d’Azure AD B2C, gestion des API et Azure Functions travaillant ensemble pour publier, sécuriser ET consommer une API !
Conseil
Si vous utilisez le niveau Consommation de la Gestion des API, au lieu de la limitation du débit par le sujet du jeton JWT ou l’adresse IP entrante, vous pouvez effectuer une limitation par quota de débit d’appels (la stratégie Limitation du débit d’appels par clé n’est pas prise en charge actuellement au niveau « Consommation »). Cliquez ici pour en savoir plus. Cet exemple étant une application monopage JavaScript, la clé Gestion des API n’est utilisée que pour les appels de limitation de débit et de facturation. L’autorisation et l’authentification proprement dites sont gérées par Azure AD B2C et encapsulées dans le jeton JWT. Celui-ci est validé deux fois, d’abord par la Gestion des API, puis par la fonction Azure back-end.
Chargement de l’exemple d’application SPA JavaScript dans un stockage statique
Toujours dans le panneau du compte de stockage, sélectionnez le panneau « Conteneurs » dans la section Service Blob et sélectionnez le conteneur $web qui apparaît dans le volet droit.
Enregistrez le code ci-dessous dans un fichier local sur votre ordinateur sous le nom index.html, puis chargez le fichier index.html dans le conteneur $web.
<!doctype html> <html lang="en"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1"> <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.0-beta2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-BmbxuPwQa2lc/FVzBcNJ7UAyJxM6wuqIj61tLrc4wSX0szH/Ev+nYRRuWlolflfl" crossorigin="anonymous"> <script type="text/javascript" src="https://alcdn.msauth.net/browser/2.11.1/js/msal-browser.min.js"></script> </head> <body> <div class="container-fluid"> <div class="row"> <div class="col-md-12"> <nav class="navbar navbar-expand-lg navbar-dark bg-dark"> <div class="container-fluid"> <a class="navbar-brand" href="#">Azure Active Directory B2C with Azure API Management</a> <div class="navbar-nav"> <button class="btn btn-success" id="signinbtn" onClick="login()">Sign In</a> </div> </div> </nav> </div> </div> <div class="row"> <div class="col-md-12"> <div class="card" > <div id="cardheader" class="card-header"> <div class="card-text"id="message">Please sign in to continue</div> </div> <div class="card-body"> <button class="btn btn-warning" id="callapibtn" onClick="getAPIData()">Call API</a> <div id="progress" class="spinner-border" role="status"> <span class="visually-hidden">Loading...</span> </div> </div> </div> </div> </div> </div> <script lang="javascript"> // Just change the values in this config object ONLY. var config = { msal: { auth: { clientId: "{CLIENTID}", // This is the client ID of your FRONTEND application that you registered with the SPA type in Azure Active Directory B2C authority: "{YOURAUTHORITYB2C}", // Formatted as https://{b2ctenantname}.b2clogin.com/tfp/{b2ctenantguid or full tenant name including onmicrosoft.com}/{signuporinpolicyname} redirectUri: "{StoragePrimaryEndpoint}", // The storage hosting address of the SPA, a web-enabled v2 storage account - recorded earlier as the Primary Endpoint. knownAuthorities: ["{B2CTENANTDOMAIN}"] // {b2ctenantname}.b2clogin.com }, cache: { cacheLocation: "sessionStorage", storeAuthStateInCookie: false } }, api: { scopes: ["{BACKENDAPISCOPE}"], // The scope that we request for the API from B2C, this should be the backend API scope, with the full URI. backend: "{APIBASEURL}/hello" // The location that we'll call for the backend api, this should be hosted in API Management, suffixed with the name of the API operation (in the sample this is '/hello'). } } document.getElementById("callapibtn").hidden = true; document.getElementById("progress").hidden = true; const myMSALObj = new msal.PublicClientApplication(config.msal); myMSALObj.handleRedirectPromise().then((tokenResponse) => { if(tokenResponse !== null){ console.log(tokenResponse.account); document.getElementById("message").innerHTML = "Welcome, " + tokenResponse.account.name; document.getElementById("signinbtn").hidden = true; document.getElementById("callapibtn").hidden = false; }}).catch((error) => {console.log("Error Signing in:" + error); }); function login() { try { myMSALObj.loginRedirect({scopes: config.api.scopes}); } catch (err) {console.log(err);} } function getAPIData() { document.getElementById("progress").hidden = false; document.getElementById("message").innerHTML = "Calling backend ... " document.getElementById("cardheader").classList.remove('bg-success','bg-warning','bg-danger'); myMSALObj.acquireTokenSilent({scopes: config.api.scopes, account: getAccount()}).then(tokenResponse => { const headers = new Headers(); headers.append("Authorization", `Bearer ${tokenResponse.accessToken}`); fetch(config.api.backend, {method: "GET", headers: headers}) .then(async (response) => { if (!response.ok) { document.getElementById("message").innerHTML = "Error: " + response.status + " " + JSON.parse(await response.text()).message; document.getElementById("cardheader").classList.add('bg-warning'); } else { document.getElementById("cardheader").classList.add('bg-success'); document.getElementById("message").innerHTML = await response.text(); } }).catch(async (error) => { document.getElementById("cardheader").classList.add('bg-danger'); document.getElementById("message").innerHTML = "Error: " + error; }); }).catch(error => {console.log("Error Acquiring Token Silently: " + error); return myMSALObj.acquireTokenRedirect({scopes: config.api.scopes, forceRefresh: false}) }); document.getElementById("progress").hidden = true; } function getAccount() { var accounts = myMSALObj.getAllAccounts(); if (!accounts || accounts.length === 0) { return null; } else { return accounts[0]; } } </script> </body> </html>Accédez au point de terminaison principal du site web statique que vous avez stocké dans la dernière section.
Notes
Félicitations, vous venez de déployer une application monopage JavaScript sur l’hébergement de contenu statique du Stockage Azure. Étant donné que nous n’avons pas encore configuré l’application JS avec vos informations Azure AD B2C, la page ne fonctionne pas si vous l’ouvrez.
Configuration de l’application SPA JavaScript pour Azure AD B2C
- Maintenant que nous savons où tout se trouve, nous pouvons configurer l’application SPA avec l’adresse de l’API Gestion des API appropriée et les bons ID client/d’application Azure AD B2C.
- Revenez au panneau Stockage du Portail Azure.
- Sélectionnez « Conteneurs » (sous « Paramètres »).
- Sélectionnez le conteneur « $web » dans la liste.
- Sélectionnez l’objet blob index.html dans la liste.
- Sélectionnez « Modifier »
- Mettez à jour les valeurs d'authentification dans la section de configuration MSAL pour qu'elles correspondent à votre application frontale que vous avez enregistrée précédemment en B2C. Utilisez les commentaires de code pour obtenir des indications sur les valeurs de configuration. La valeur authority doit être au format https://{b2ctenantname}.b2clogin.com/tfp/{b2ctenantname}.onmicrosoft.com}/{signupandsigninpolicyname}. Si vous avez utilisé nos exemples de noms et que votre locataire B2C est appelé « contoso », l’autorité devrait être « https://contoso.b2clogin.com/tfp/contoso.onmicrosoft.com/Frontendapp_signupandsignin ».
- Définissez les valeurs de l’API pour qu’elles correspondent à votre adresse principale (URL de base de l’API que vous avez enregistrée précédemment, et les valeurs « b2cScopes » ont été enregistrées précédemment pour l’application back-end).
- Sélectionnez Enregistrer
Définir les URI de redirection pour l’application front-end Azure AD B2C
Ouvrez le panneau Azure AD B2C, puis accédez à l’inscription d’application pour l’application front-end JavaScript.
Sélectionnez « URI de redirection » et supprimez l’espace réservé «https://jwt.ms » que nous avons entré précédemment.
Ajoutez un nouvel URI pour le point de terminaison (de stockage) principal (sans la barre oblique de fin).
Notes
Cette configuration entraînera la réception, par un client de l’application front-end, d’un jeton d’accès avec les revendications appropriées en provenance d’Azure AD B2C. L’application monopage sera en mesure de l’ajouter en tant que jeton du porteur dans l’en-tête HTTPS de l’appel à l’API back-end.
La Gestion des API prévalide le jeton, limite le débit des appels au point de terminaison à la fois par le sujet du jeton JWT émis par l’ID Azure (l’utilisateur) et par l’adresse IP de l’appelant (selon le niveau de service de la Gestion des API, cf. remarque ci-dessus), avant de transmettre la demande à l’API de la fonction Azure réceptrice, en ajoutant la clé de sécurité de la fonction. L’application monopage affichera la réponse dans le navigateur.
Félicitations, vous avez configuré Azure AD B2C, Gestion des API Azure, Azure Functions et l’autorisation Azure App Service pour opérer en parfaite harmonie !
Maintenant que nous avons une application simple avec une API sécurisée simple, testons-la.
Tester l’application cliente
- Ouvrez l’URL de l’exemple d’application que vous avez notée à partir du compte de stockage créé plus tôt.
- Sélectionnez « Se connecter » dans le coin supérieur droit, cette action affiche votre profil d’inscription ou de connexion Azure AD B2C.
- L’application devrait vous accueillir par le nom de votre profil B2C.
- Sélectionnez maintenant « Appeler l’API » et la page doit être mise à jour avec les valeurs renvoyées à partir de votre API sécurisée.
- Si vous sélectionnez à plusieurs reprises le bouton Appeler l’API et que vous exécutez le niveau développeur ou supérieur de Gestion des API, vous devez noter que votre solution commence à limiter la limite de l’API et que cette fonctionnalité doit être signalée dans l’application avec un message approprié.
Nous avons terminé.
Les étapes ci-dessus peuvent être adaptées et modifiées pour autoriser de nombreuses utilisations différentes d’Azure AD B2C avec Gestion des API.
Contenu connexe
- En savoir plus sur Microsoft Entra ID et OAuth2.0.
- Consultez plus d’informations sur gestion des API.
- Pour les autres méthodes permettant de sécuriser votre service principal, consultez Authentification mutuelle des certificats.
- Création d’une instance du service Gestion des API.
- Gérer votre première API.