Skydda serverlösa API:er med Azure API Management och Azure AD B2C för förbrukning från ett SPA

2025-06-02

GÄLLER FÖR: Alla API Management-nivåer

Viktigt!

Från och med den 1 maj 2025 är Azure AD B2C inte längre tillgängligt att köpa för nya kunder. Läs mer i våra vanliga frågor och svar.

Det här scenariot visar hur du konfigurerar din Azure API Management-instans för att skydda ett API. Vi använder flödet Azure AD B2C SPA (Auth Code + PKCE) för att hämta en token, tillsammans med API Management för att skydda en Azure Functions-serverdel med hjälp av EasyAuth.

En konceptuell översikt över API-auktorisering finns i Autentisering och auktorisering till API:er i API Management.

Mål

Vi kommer att se hur API Management kan användas i ett förenklat scenario med Azure Functions och Azure AD B2C. Du skapar en JavaScript-app (JS) som anropar ett API som loggar in användare med Azure AD B2C. Sedan använder du API Management-funktionerna validate-jwt, CORS och Rate Limit By Key för att skydda serverdels-API:et.

För skydd på djupet använder vi sedan EasyAuth för att verifiera token igen i serverdels-API:et och se till att API-hantering är den enda tjänst som kan anropa Azure Functions-serverdelen.

Vad kommer du att lära dig

Konfiguration av en enkeltsidesapplikation och serverdels-API i Azure Active Directory B2C
Skapa ett Azure Functions-serverdels-API
Import av ett Azure Functions-API till Azure API Management
Skydda API:et i Azure API Management
Kalla på Azure Active Directory B2C-autoriseringsslutpunkterna via biblioteken för Microsofts identitetsplattform (MSAL.js)
Lagra ett HTML-/Vanilla JS-enkelsidigt program och hantera det från en Azure Blob Storage-slutpunkt

Förutsättningar

Om du vill följa stegen i den här artikeln måste du ha:

Ett Azure (StorageV2) allmän användning V2 Storage-konto för att vara värd för frontendens JS-enkelsidesapplikation.
En Azure API Management-instans (alla nivåer fungerar, inklusive "Förbrukning", men vissa funktioner som gäller för det fullständiga scenariot är inte tillgängliga på den här nivån (hastighetsgräns per nyckel och dedikerad virtuell IP) beskrivs dessa begränsningar nedan i artikeln där det är lämpligt).
En tom Azure Functions-app (som kör V3.1 .NET Core-runtime på en förbrukningsplan) för att vara värd åt det anropade API:et
En Azure AD B2C-klientorganisation som är länkad till en prenumeration.

Även om du i praktiken använder resurser i samma region i produktionsarbetsbelastningar är distributionsregionen inte viktig för den här instruktionsartikeln.

Översikt

Här är en bild av de komponenter som används och flödet mellan dem när processen är klar. Komponenter i användning och flöde

Här är en snabb översikt över stegen:

Skapa Azure AD B2C-samtal (frontend, API Management) och API-applikationer med önskade omfång och ge API-åtkomst
Skapa registrerings- och inloggningsprinciperna så att användare kan logga in med Azure AD B2C
Konfigurera API Management med nya Azure AD B2C-klient-ID:n och nycklar för att aktivera OAuth2-användarauktorisering i utvecklarkonsolen
Skapa funktions-API:et
Konfigurera Function API:et för att aktivera EasyAuth med de nya Azure AD B2C-klient-ID:n och nycklarna och begränsa åtkomsten till APIM VIP.
Skapa API-definitionen i API Management
Konfigurera OAuth2 för API Management API-konfigurationen
Konfigurera CORS-principen och lägg till principen validate-jwt för att verifiera OAuth-token för varje inkommande begäran
Skapa det anropande programmet för att använda API:et
Ladda upp JS SPA-exemplet
Konfigurera JS-exempelklientappen med de nya Azure AD B2C-klient-ID:n och nycklarna
Testa klientprogrammet

Tips

Vi kommer att samla in en hel del information och nycklar osv. när vi går i det här dokumentet kan det vara praktiskt att ha en textredigerare öppen för att lagra följande konfigurationsobjekt tillfälligt.

B2C SERVERDELSKLIENT-ID: B2C SERVERDELSKLIENTHEMLIGHETSNYCKEL: B2C SERVERDEL API OMFÅNGS-URI: B2C FRONTENDEL KLIENT-ID: B2C ANVÄNDARFLÖDE SLUTPUNKT-URI: B2C VÄLKÄND OPENID-SLUTPUNKT: B2C POLICY-NAMN: Frontendapp_signupandsignin FUNKTIONS-URL: APIM API BAS-URL: LAGRING PRIMÄR SLUTPUNKT-URL:

Konfigurera backend-applikationen

Öppna bladet Azure AD B2C i portalen och utför följande steg.

Välj fliken Appregistreringar
Välj knappen Ny registrering.
Välj "Webb" i urvalsrutan Omdirigerings-URI.
Ställ nu in Visningsnamn, välj något unikt och relevant för den tjänst som skapas. I det här exemplet använder vi namnet "Serverdelsprogram".
Använd platshållare för svars-URL:erna, till exempel "https://jwt.ms" (en Microsoft-ägd token avkodningswebbplats), vi uppdaterar dessa URL:er senare.
Kontrollera att du har valt alternativet "Konton i en identitetsprovider eller organisationskatalog (för att autentisera användare med användarflöden)"
För det här exemplet avmarkerar du rutan "Bevilja administratörsmedgivande", eftersom vi inte behöver offline_access behörigheter i dag.
Välj "Registrera".
Registrera klient-ID:t för backendprogrammet för senare användning (visas under Program-ID (klient-ID)).
Välj fliken Certifikat och hemligheter (under Hantera) och välj sedan "Ny klienthemlighet" för att generera en autentiseringsnyckel (Acceptera standardinställningarna och välj Lägg till).
När du klickar på Lägg till kopierar du nyckeln (under "värde") någonstans som är säker för senare användning som "Klienthemlighet för serverdelen" – observera att den här dialogrutan är den enda chansen att du behöver kopiera den här nyckeln.
Välj nu fliken Exponera ett API (under Hantera).
Du uppmanas att ange AppID-URI:n, välja och registrera standardvärdet.
Skapa och ge omfånget namnet "Hello" för funktions-API:et. Du kan använda frasen "Hello" för alla alternativ som kan anges, registrera den ifyllda URI:n för fullständigt omfång och sedan välja Lägg till omfång.
Gå tillbaka till roten av Azure AD B2C-panelen genom att välja 'Azure AD B2C'-navigeringslänken längst upp till vänster i portalen.

Anteckning

Azure AD B2C-omfång är i praktiken behörigheter i ditt API som andra program kan begära åtkomst till via API-åtkomstbladet från sina program, i själva verket har du precis skapat programbehörigheter för ditt kallade API.

Konfigurera frontend-applikationen

Välj fliken Appregistreringar
Välj knappen Ny registrering.
Välj "Single Page Application (SPA)" i valboxen Omdirigerings-URI.
Ange nu visningsnamn och AppID-URI, välj något unikt och relevant för klientdelsprogrammet som ska använda den här Azure Active Directory B2C-appregistreringen. I det här exemplet kan du använda "Klientdelsprogram"
Enligt den första appregistreringen låter du valet av kontotyper som stöds vara standard (autentisera användare med användarflöden)
Använd platshållare för svars-URL:erna, till exempel "https://jwt.ms" (en Microsoft-ägd token avkodningswebbplats), vi uppdaterar dessa URL:er senare.
Låt rutan bevilja administratörsmedgivande vara markerad
Välj "Registrera".
Anteckna klient-ID:t för frontend-applikationen för senare användning (visas under 'Applikation (klient-ID)').
Växla till fliken API-behörigheter .
Bevilja åtkomst till serverdelsprogrammet genom att klicka på "Lägg till en behörighet", sedan "Mina API:er", välj "Serverdelsprogram", välj Behörigheter, välj det omfång som du skapade i föregående avsnitt och välj Lägg till behörigheter
Välj "Bevilja administratörsmedgivande för {klient} och välj "Ja" i popup-dialogrutan. Det här popup-fönstret godkänner att "Klientdelsprogrammet" använder behörigheten "hello" som definierades i "Serverdelsprogrammet" som skapades tidigare.
Alla behörigheter bör nu visas för appen som en grön bock under statuskolumnen

Gå tillbaka till B2C-bladets rot genom att välja Azure AD B2C-sökväg.
Växla till fliken Användarflöden (under principer).
Välj "Nytt användarflöde"
Välj användarflödestypen "Registrering och inloggning" och välj "Rekommenderas" och sedan "Skapa"
Ge principen ett namn och registrera den för senare. I det här exemplet kan du använda "Frontendapp_signupandsignin", observera att detta kommer att prefixeras med "B2C_1_" för att göra "B2C_1_Frontendapp_signupandsignin"
Under Identitetsprovidrar och Lokala konton kontrollerar du "Registrera dig via e-post" (eller "Användar-ID registrerar dig" beroende på konfigurationen för din B2C-klientorganisation) och väljer OK. Den här konfigurationen är på grund av att vi registrerar lokala B2C-konton, inte förlitar oss på en annan identitetsleverantör (till exempel en social identitetsleverantör) för att använda ett befintligt socialt mediekonto.
Låt inställningarna för MFA och villkorlig åtkomst vara kvar som standard.
Under "Användarattribut och anspråk" väljer du "Visa mer..." välj sedan de anspråksalternativ som du vill att användarna ska ange och som har returnerats i token. Kontrollera minst "Visningsnamn" och "e-postadress" för att samla in, och "Visningsnamn" och "e-postadresser" för att returnera (var noga med att du samlar in en e-postadress, singular, och begär att returnera e-postadresser, plural), och välj "OK", välj sedan "Skapa".
Välj det användarflöde som du skapade i listan och välj sedan knappen Kör användarflöde.
Den här åtgärden öppnar sidan för att köra användarflöde. Välj frontend-applikationen, kopiera användarflödets slutpunkt och spara den för senare.
Kopiera och lagra länken överst och spela in som den välkända openid-konfigurationsslutpunkten för senare användning.

Anteckning

Med B2C-principer kan du exponera Azure AD B2C-inloggningsslutpunkter för att kunna samla in olika datakomponenter och logga in användare på olika sätt.

I det här fallet konfigurerade vi ett registrerings- eller inloggningsflöde (princip). Detta exponerade också en välkänd konfigurationsslutpunkt, i båda fallen identifierades vår skapade princip i URL:en av frågesträngsparametern "p=".

När detta är klart har du nu en funktionell plattform för företags-till-konsumentidentitet som loggar in användare i flera program.

Skapa funktions-API:et

Växla tillbaka till din standardklient för Microsoft Entra i Azure-portalen så att vi kan konfigurera objekt i din prenumeration igen.
Gå till bladet Funktionsappar i Azure-portalen, öppna den tomma funktionsappen och välj sedan Funktioner, välj Lägg till.
I den utfällbara menyn som visas väljer du "Utveckla i portalen", under "välj en mall" och väljer sedan "HTTP-utlösare", under Mallinformationen heter den "hello" med auktoriseringsnivån "Funktion" och väljer sedan Lägg till.
Växla till bladet Kod + Test och kopiera och klistra in exempelkoden nedan över den befintliga koden som visas.

Välj Spara.


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()}");
}

Tips

C#-skriptets funktionskod som du precis klistrade in loggar bara en rad till funktionsloggarna och returnerar texten "Hello World" med vissa dynamiska data (datum och tid).

Välj "Integrering" på det vänstra bladet och välj sedan länken http (req) i rutan Utlösare.
I listrutan "Valda HTTP-metoder" avmarkerar du metoden http POST, lämnar endast GET valt och väljer sedan Spara.
Växla tillbaka till fliken Kod + Test, välj Hämta funktions-URL och kopiera sedan url:en som visas och spara den för senare.

Anteckning

Bindningarna du nyss skapade säger helt enkelt till Functions att svara på anonyma http GET-begäranden till den URL som du precis kopierade (https://yourfunctionappname.azurewebsites.net/api/hello?code=secretkey). Nu har vi ett skalbart serverlöst https-API som kan returnera en enkel nyttolast.

Du kan nu testa att anropa det här API:et från en webbläsare med din version av URL:en ovan som du precis kopierade och sparade. Du kan också ta bort frågesträngsparametrarna "?code=secretkey" i URL:en och testa igen för att bevisa att Azure Functions returnerar ett 401-fel.

Konfigurera och skydda funktions-API:et

Två extra områden i funktionsappen måste konfigureras (auktorisering och nätverksbegränsningar).
Först ska vi konfigurera autentisering/auktorisering, så gå tillbaka till rotpanelen för funktionsappen via navigeringslänken.
Välj sedan "Autentisering" (under Inställningar).
Välj Lägg till identitetsprovider
I listrutan Identitetsprovider väljer du "Microsoft"
För Appregistrering väljer du "Ange information om en befintlig appregistrering"
Klistra in serverdelsprogrammets klient-ID (från Azure AD B2C) i rutan Program-ID (klient-ID) (vi registrerade den här konfigurationen tidigare).
Klistra in den välkända OpenID-konfigurationsslutpunkten från registrerings- och inloggningspolicyn i utfärdarens URL-överfält (vi noterade denna konfiguration tidigare).
Klistra in serverdelsprogrammets klienthemlighet i lämplig ruta (vi spelade in den här konfigurationen tidigare).
För "Oautentiserade begäranden" väljer du "HTTP 401 Obehörig: rekommenderas för API:er"
Lämna Token Store aktiverat (standard).
Välj Spara (längst upp till vänster på bladet).

Viktigt!

Nu har funktions-API:et distribuerats och bör skicka 401-svar om rätt JWT inte anges som ett auktorisering: Bearer-huvud och bör returnera data när en giltig begäran görs. Du har lagt till ytterligare skydd på djupet i EasyAuth genom att konfigurera alternativet "Logga in med Microsoft Entra-ID" för att hantera oautentiserade begäranden.

Vi har fortfarande ingen IP-säkerhet tillämpad, om du har en giltig nyckel och OAuth2-token kan vem som helst anropa detta var som helst – helst vill vi tvinga alla begäranden att komma via API Management.

Om du använder nivåerna API Management Consumption, Basic v2, Standard v2 och Premium v2 finns det ingen dedikerad virtuell IP-adress för Azure API Management för att tillåta listan med funktioners åtkomstbegränsningar. På de klassiska (dedikerade) nivåerna av Azure API Management är VIP:en en singeltenant och gäller för resursens livslängd. För de nivåer som körs på delad infrastruktur kan du låsa dina API-anrop via den delade hemliga funktionsnyckeln i den del av URI:n som du kopierade ovan. För dessa nivåer gäller inte heller steg 12–17 nedan.
Stäng bladet "Autentisering" från App Service/Functions-portalen.
Öppna API Management-bladet i portalen och öppna sedan instansen.
Registrera den privata VIP som visas på översiktsfliken.
Gå tillbaka till Azure Functions-bladet i portalen och öppna sedan din instans igen.
Välj Nätverk och välj sedan Konfigurera åtkomstbegränsningar
Välj "Lägg till regel" och ange VIP:en som kopierades i steg 3 ovan i formatet xx.xx.xx.xx/32.
Om du vill fortsätta att interagera med funktionsportalen och utföra de valfria stegen nedan bör du lägga till din egen offentliga IP-adress eller ditt CIDR-intervall även här.
När det finns en tillåtsinmatning i listan lägger Azure till en implicit regel som nekar för att blockera alla andra adresser.

Du måste lägga till CIDR-formaterade adressblock i panelen IP-begränsningar. När du behöver lägga till en enda adress, till exempel API Management VIP, måste du lägga till den i formatet xx.xx.xx.xx/32.

Anteckning

Nu bör funktions-API:et inte vara anropsbart från någon annanstans än via API-hantering eller din adress.

Öppna API Management-panelen och öppna därefter din instans.
Välj bladet för API:er (under API:er).
I fönstret Lägg till ett nytt API väljer du Funktionsapp och väljer sedan "Fullständig" överst i popup-fönstret.
Klicka på Bläddra, välj den funktionsapp som du är värd för API:et i och klicka på Välj. Klicka sedan på Välj igen.
Ge API:et ett namn och en beskrivning för API Managements interna användning och lägg till det i den "obegränsade" produkten.
Kopiera och registrera API:ets "bas-URL" och välj "skapa".
Välj fliken Inställningar och stäng sedan kryssrutan "Prenumeration krävs" under Prenumeration – eftersom vi använder OAuth JWT i det här fallet för att betygsätta gränsen. Observera att om du använder förbrukningsnivån krävs detta fortfarande i en produktionsmiljö.

Tips

Om du använder konsumtionsnivån för APIM blir den obegränsade produkten inte tillgänglig som en del av standardutbudet. Navigera i stället till "Produkter" under "API:er" och tryck på "Lägg till". Skriv "Obegränsat" som produktnamn och beskrivning och välj det API som du precis lade till från pratbubblan "+" API:er längst ned till vänster på skärmen. Markera kryssrutan "publicerad". Lämna resten som standard. Tryck slutligen på knappen "skapa". Detta skapade den "obegränsade" produkten och tilldelade den till ditt API. Du kan anpassa din nya produkt senare.

Konfigurera och samla in rätt inställningar för lagringsändpunkter

Öppna visningssidan för lagringskonton i Azure-portalen
Välj det konto som du skapade och välj bladet "Statisk webbplats" i avsnittet Inställningar (om du inte ser alternativet "Statisk webbplats" kontrollerar du att du har skapat ett V2-konto).
Ange den statiska webbvärdfunktionen till "aktiverad" och ange indexdokumentets namn tillindex.htmloch välj sedan Spara.
Anteckna innehållet i den 'primära slutpunkten' för senare, eftersom den här platsen är där frontend-webbsidan kommer att finnas.

Tips

Du kan använda antingen Azure Blob Storage + CDN-omskrivning eller Azure App Service för att vara värd för en SPA, men den statiska webbplatsfunktionen i Azure Blob Storage ger oss en standardcontainer för att tillhandahålla statiskt webbinnehåll som HTML, JS och CSS från Azure Storage och kommer att härleda en standardsida åt oss utan ansträngning.

Konfigurera CORS och validate-jwt-principer

Följande avsnitt bör följas oavsett vilken APIM-nivå som används. Url:en för lagringskontot kommer från det lagringskonto som du har gjort tillgängligt från förutsättningarna överst i den här artikeln.

Växla till API-hanteringsbladet i portalen och öppna instansen.
Välj API:er och välj sedan "Alla API:er".
Under "Inkommande bearbetning" väljer du kodvisningsknappen "</>" för att visa principredigeraren.
Redigera avsnittet inkommande och klistra in xml-koden nedan så att den ser ut ungefär så här.
Ersätt följande parametrar i policyn
{PrimaryStorageEndpoint} (Den primära lagringsslutpunkten som du kopierade i föregående avsnitt), {b2cpolicy-well-known-openid} (den välkända openid-konfigurationsslutpunkten som du kopierade tidigare) och {backend-api-application-client-id} (B2C-programmet/klient-ID:t för serverdels-API:et) med rätt värden som sparades tidigare.
Om du använder förbrukningsnivån för API Management bör du ta bort båda principerna rate-limit-by-key eftersom dessa principer inte är tillgängliga när du använder förbrukningsnivån för Azure API Management.
```
<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>
```
Anteckning

Nu kan Azure API-hanteringen svara på begäranden mellan ursprung från dina JavaScript SPA-appar, och den utför begränsning, hastighetsbegränsning och förvalidering av JWT-autentiseringstoken som skickas INNAN begäran vidarebefordras till funktions-API:et.

Grattis, nu har du Azure AD B2C, API Management och Azure Functions som arbetar tillsammans för att publicera, skydda OCH använda ett API!

Tips

Om du använder API Management-förbrukningsnivå kan du istället för att begränsa hastigheten efter JWT-ämne eller inkommande IP-adress (att begränsa anropsfrekvensen efter nyckelprincip stöds inte i dag för "Förbrukning"-nivån) begränsa efter anropsfrekvenskvot, se här. Eftersom det här exemplet är ett JavaScript-ensidesprogram använder vi ENDAST API Management-nyckeln för hastighetsbegränsning och faktureringsanrop. Den faktiska auktoriseringen och autentiseringen hanteras av Azure AD B2C och kapslas in i JWT, som verifieras två gånger, en gång av API Management och sedan av serverdelens Azure-funktion.

Ladda upp JavaScript SPA-exemplet till statisk lagring

I panelen för lagringskonto, välj panelen "Containrar" i avsnittet Blob Service och välj “$web”-containern som visas i den högra rutan.

Spara koden nedan i en fil lokalt på datorn som index.html och ladda sedan upp filen index.html till containern $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>

Bläddra till den statiska webbplatsens primära slutpunkt som du lagrade tidigare i det senaste avsnittet.

Anteckning

Grattis, du har precis distribuerat en JavaScript-enkelsidesapp till Azure Storage Static Content Hosting. Eftersom vi inte har konfigurerat JS-appen med din Azure AD B2C-information ännu – kommer sidan inte att fungera ännu om du öppnar den.

Konfigurera JavaScript SPA för Azure AD B2C

Nu vet vi var allt är: vi kan konfigurera SPA med rätt API Management API-adress och rätt Azure AD B2C-applikation/klient-ID:n.
Gå tillbaka till Azure portalens lagringspanel
Välj "Containrar" (under Inställningar)
Välj containern "$web" i listan
Välj index.html blob i listan
Välj Redigera
Uppdatera autentiseringsvärdena i avsnittet MSAL-konfiguration så att det matchar ditt klientdelsprogram som du registrerade i B2C tidigare. Använd kodkommentarna för tips om hur konfigurationsvärdena ska se ut. Myndighetens värde måste vara i formatet:- https://{b2ctenantname}.b2clogin.com/tfp/{b2ctenantname}.onmicrosoft.com/{signupandsigninpolicyname}, om du har använt våra exempelnamn och din b2c-klientorganisation kallas "contoso" så förväntar du dig att myndigheten är "https://contoso.b2clogin.com/tfp/contoso.onmicrosoft.com/Frontendapp_signupandsignin".
Ange API-värdena så att de matchar din serverdelsadress (API-bas-URL:en som du registrerade tidigare, och värdena för "b2cScopes" registrerades tidigare för serverdelsprogrammet).
Välj Spara

Ange omdirigerings-URI:er för Azure AD B2C-klientdelsappen

Öppna Azure AD B2C-sektionen och gå till programregistreringen för JavaScript-front-end-applikationen.
Välj 'Omdirigerings-URI:er' och ta bort platshållaren 'https://jwt.ms' vi angav tidigare.
Lägg till en ny URI för den primära lagringsslutpunkten utan det avslutande snedstrecket.

Anteckning

Den här konfigurationen resulterar i att en klient för klientdelsprogrammet får en åtkomsttoken med lämpliga anspråk från Azure AD B2C. SPA kommer att kunna lägga till detta som en bärartoken i HTTP-huvudet i anropet till bakgrunds-API:et.

API Management kommer att förvalidera token, sätta begränsningar på anropsfrekvensen till slutpunkten baserat på både ämnet för JWT som utfärdats av Azure ID (användaren) och av anroparens IP-adress (beroende på tjänstenivån för API Management, se anteckningen ovan), innan begäran skickas vidare till det mottagande Azure Function API:et och funktionssäkerhetsnyckeln läggs till. SPA återger svaret i webbläsaren.

Grattis, du har konfigurerat Azure AD B2C, Azure API Management, Azure Functions, Azure App Service Authorization för att fungera i perfekt harmoni!

Nu har vi en enkel app med ett enkelt skyddat API. Nu ska vi testa den.

Testa klientprogrammet

Öppna exempelappens URL som du antecknade från lagringskontot som du skapade tidigare.
Välj "Logga in" i det övre högra hörnet. Den här åtgärden visar din Azure AD B2C-registrering eller inloggningsprofil.
Appen bör välkomna dig med ditt B2C-profilnamn.
Välj nu "Anropa API" så bör sidan uppdateras med de värden som skickas tillbaka från ditt skyddade API.
Om du upprepade gånger väljer knappen Anropa API och du kör på utvecklarnivån eller senare i API Management bör du tänka på att din lösning börjar betygsätta gränsen för API:et och att den här funktionen ska rapporteras i appen med ett lämpligt meddelande.

Och vi är klara

Stegen ovan kan anpassas och redigeras för att tillåta många olika användningar av Azure AD B2C med API Management.

Läs mer om Microsoft Entra ID och OAuth2.0.
Läs mer om API Management.
Andra sätt att skydda serverdelstjänsten finns i Ömsesidig certifikatautentisering.
Skapa en API Management-tjänstinstans.
Hantera ditt första API.

Feedback

Var den här sidan till hjälp?