Autentisering och auktorisering i Azure App Service och Azure Functions

2025-04-10

Azure App Service tillhandahåller inbyggd autentisering (inloggning av användare) och auktorisering (ger åtkomst till säkra data) funktioner. Dessa funktioner kallas ibland För enkel autentisering. Du kan använda dem för att logga in användare och komma åt data genom att skriva lite eller ingen kod i webbappen, RESTful API, mobil server och funktioner.

Den här artikeln beskriver hur App Service förenklar autentisering och auktorisering för din app.

Anledningar till att använda inbyggd autentisering

Om du vill implementera autentisering och auktorisering kan du använda de paketerade säkerhetsfunktionerna i ditt webbramverk eller skriva egna verktyg. Det kan ta mycket tid att implementera en säker lösning för autentisering och auktorisering. Du måste följa branschens bästa praxis och standarder. Du måste också se till att din lösning håller sig uppdaterad med de senaste säkerhets-, protokoll- och webbläsaruppdateringarna.

De inbyggda funktionerna i App Service och Azure Functions kan spara tid och arbete genom att tillhandahålla out-of-the-box-autentisering med federerade identitetsprovidrar, så att du kan fokusera på resten av ditt program.

Med App Service kan du integrera autentiseringsfunktioner i webbappen eller API:et utan att implementera dem själv. Den här funktionen är inbyggd direkt i plattformen och kräver inte något särskilt språk, SDK, säkerhetsexpertis eller kod. Du kan integrera den med flera inloggningsleverantörer, till exempel Microsoft Entra, Facebook, Google och X.

Din app kan behöva stöd för mer komplexa scenarier, till exempel Visual Studio-integrering eller inkrementellt medgivande. Det finns flera autentiseringslösningar som stöder dessa scenarier. Mer information finns i Autentiseringsscenarier och rekommendationer.

Identitetsprovidrar

App Service använder federerad identitet. En Microsoft- eller icke-Microsoft-identitetsprovider hanterar användaridentiteter och autentiseringsflöde åt dig. Följande identitetsprovidrar är tillgängliga som standard:

Leverantör	Inloggningsslutpunkt	Vägledning
Microsoft Entra	`/.auth/login/aad`	Inloggning för App Service Microsoft Entra-plattformen
Facebook	`/.auth/login/facebook`	Inloggning med App Service Facebook
Google	`/.auth/login/google`	Inloggning med App Service Google
X	`/.auth/login/x`	App Service X inloggning
GitHub (på engelska)	`/.auth/login/github`	GitHub-inloggning för App Service
Äpple	`/.auth/login/apple`	App Service-inloggning via Apple-inloggning (förhandsversion)
Alla OpenID Connect-provider	`/.auth/login/<providerName>`	Inloggning med App Service OpenID Connect

När du konfigurerar den här funktionen med någon av dessa leverantörer är dess inloggningsslutpunkt tillgänglig för användarautentisering och för validering av autentiseringstoken från providern. Du kan ge användarna valfritt antal av dessa inloggningsalternativ.

Överväganden för att använda inbyggd autentisering

Om du aktiverar inbyggd autentisering omdirigeras alla begäranden till ditt program automatiskt till HTTPS, oavsett konfigurationsinställningen för App Service för att framtvinga HTTPS. Du kan inaktivera den här automatiska omdirigeringen med hjälp requireHttps av inställningen i V2-konfigurationen. Vi rekommenderar dock att du fortsätter att använda HTTPS och ser till att inga säkerhetstoken någonsin överförs via icke-säkra HTTP-anslutningar.

Du kan använda App Service för autentisering med eller utan att begränsa åtkomsten till webbplatsinnehåll och API:er. Ange åtkomstbegränsningar i avsnittet Inställningar>Autentiseringsinställningar för> i webbappen:

Om du vill begränsa appåtkomsten till endast autentiserade användare anger du Åtgärd att vidta när begäran inte autentiseras för att logga in med någon av de konfigurerade identitetsprovidrar.
Om du vill autentisera men inte begränsa åtkomsten anger du Åtgärd att vidta när begäran inte autentiseras till Tillåt anonyma begäranden (ingen åtgärd).

Viktigt!

Du bör ge varje appregistrering egen behörighet och sitt medgivande. Undvik behörighetsdelning mellan miljöer genom att använda separata appregistreringar för separata distributionsfack. När du testar ny kod kan den här metoden hjälpa till att förhindra att problem påverkar produktionsappen.

Hur det fungerar

Funktionsarkitektur

Komponenten för mellanprogram för autentisering och auktorisering är en funktion i plattformen som körs på samma virtuella dator som ditt program. När du aktiverar den skickas varje inkommande HTTP-begäran genom komponenten innan programmet hanterar den.

Plattformsmellanprogrammet hanterar flera saker för din app:

Autentiserar användare och klienter med angivna identitetsprovidrar
Validerar, lagrar och uppdaterar OAuth-token som har utfärdats av de konfigurerade identitetsleverantörerna.
Hanterar den autentiserade sessionen
Injekterar identitetsinformation i HTTP-förfrågningshuvuden

Modulen körs separat från programkoden. Du kan konfigurera det med hjälp av Azure Resource Manager-inställningar eller med hjälp av en konfigurationsfil. Inga SDK:er, specifika programmeringsspråk eller ändringar i programkoden krävs.

Funktionsarkitektur i Windows (distribution som inte är en container)

Modulen för autentisering och auktorisering körs som en intern IIS-modul i samma sandbox-miljö som ditt program. När du aktiverar den skickas varje inkommande HTTP-begäran genom den innan programmet hanterar den.

Funktionsarkitektur i Linux och containrar

Modulen för autentisering och auktorisering körs i en separat container som är isolerad från programkoden. Modulen använder mönstret Ambassadör för att interagera med inkommande trafik för att utföra liknande funktioner som i Windows. Eftersom den inte körs i processen går det inte att integrera direkt med specifika språkramverk. Den relevanta information som din app behöver skickas dock i begärandehuvuden.

Autentiseringsflöde

Autentiseringsflödet är detsamma för alla leverantörer. Den skiljer sig beroende på om du vill logga in med providerns SDK:

Utan provider-SDK: Programmet delegerar federerad inloggning till App Service. Den här delegeringen är vanligtvis fallet med webbläsarappar, som kan presentera providerns inloggningssida för användaren. Serverkoden hanterar inloggningsprocessen, så den kallas även för serverstyrt flöde eller serverflöde.

Det här fallet gäller för webbläsarappar och mobilappar som använder en inbäddad webbläsare för autentisering.
Med provider-SDK: Programmet loggar in användare till providern manuellt. Sedan skickar den autentiseringstoken till App Service för validering. Den här processen är vanligtvis fallet med webbläsarlösa appar, som inte kan presentera providerns inloggningssida för användaren. Programkoden hanterar inloggningsprocessen, så den kallas även för klientstyrt flöde eller klientflöde.

Det här fallet gäller rest-API:er, Azure Functions och JavaScript-webbläsarklienter, förutom webbläsarappar som behöver mer flexibilitet i inloggningsprocessen. Det gäller även för interna mobilappar som loggar in användare med hjälp av leverantörens SDK.

Anrop från en betrodd webbläsarapp i App Service till ett annat REST-API i App Service eller Azure Functions kan autentiseras via det serverstyrda flödet. Mer information finns i Anpassa inloggning och utloggning i Azure App Service-autentisering.

I följande tabell visas stegen i autentiseringsflödet.

Steg	Utan provider-SDK	Med leverantör-SDK
1. Logga in användaren	Providern omdirigerar klienten till `/.auth/login/<provider>`.	Klientkoden loggar in användaren direkt med providerns SDK och tar emot en autentiseringstoken. Mer information finns i leverantörens dokumentation.
2. Genomför efterautentisering	Providern omdirigerar klienten till `/.auth/login/<provider>/callback`.	Klientkoden publicerar token från providern till `/.auth/login/<provider>` för validering.
3. Upprätta en autentiserad session	App Service lägger till en autentiserad cookie i svaret.	App Service returnerar en egen autentiseringstoken till klientkoden.
4. Servera autentiserat innehåll	Klienten innehåller en autentiseringscookie i efterföljande begäranden (hanteras automatiskt av webbläsaren).	Klientkoden presenterar autentiseringstoken i `X-ZUMO-AUTH` huvud.

För klientwebbläsare kan App Service automatiskt dirigera alla oautentiserade användare till /.auth/login/<provider>. Du kan också presentera användare med en eller flera /.auth/login/<provider> länkar för att logga in på din app med valfri leverantör.

Auktoriseringsbeteende

I Azure-portalen kan du konfigurera App Service med olika beteenden när en inkommande begäran inte autentiseras. I följande avsnitt beskrivs alternativen.

Viktigt!

Som standard tillhandahåller den här funktionen endast autentisering, inte auktorisering. Ditt program kan fortfarande behöva fatta auktoriseringsbeslut, förutom de kontroller som du konfigurerar här.

Begränsad åtkomst

Tillåt oautentiserade begäranden: Det här alternativet skjuter upp auktoriseringen av oautentiserad trafik till din programkod. För autentiserade begäranden skickar App Service även autentiseringsinformation i HTTP-huvudena.

Det här alternativet ger större flexibilitet vid hantering av anonyma begäranden. Du kan till exempel presentera flera inloggningsleverantörer för dina användare. Du måste dock skriva kod.
Kräv autentisering: Det här alternativet avvisar all oautentiserad trafik till ditt program. Specifika åtgärder som ska vidtas anges i avsnittet Oautentiserade begäranden senare i den här artikeln.

Med det här alternativet behöver du inte skriva någon autentiseringskod i din app. Du kan hantera finare auktorisering, till exempel rollspecifik auktorisering, genom att granska användarens anspråk.

Försiktighet

Att begränsa åtkomsten på det här sättet gäller för alla anrop till din app, vilket kanske inte är önskvärt för appar som vill ha en offentligt tillgänglig startsida, som i många ensidesprogram. Om undantag behövs måste du konfigurera undantagna sökvägar i en konfigurationsfil.

Anmärkning

När du använder Microsofts identitetsprovider för användare i din organisation är standardbeteendet att alla användare i din Microsoft Entra-klientorganisation kan begära en token för din app. Du kan konfigurera programmet i Microsoft Entra om du vill begränsa åtkomsten till din app till en definierad uppsättning användare. App Service erbjuder också några grundläggande inbyggda auktoriseringskontroller som kan hjälpa dig med vissa valideringar. Mer information om auktorisering i Microsoft Entra finns i Grunderna för Microsoft Entra-auktorisering.

När du använder Microsofts identitetsprovider för användare i din organisation är standardbeteendet att alla användare i din Microsoft Entra-klientorganisation kan begära en token för ditt program. Du kan konfigurera programmet i Microsoft Entra om du vill begränsa åtkomsten till din app till en definierad uppsättning användare. App Service erbjuder också några grundläggande inbyggda auktoriseringskontroller som kan hjälpa dig med vissa valideringar. Mer information om auktorisering i Microsoft Entra finns i Grunderna för Microsoft Entra-auktorisering.

Oautentiserade begäranden

HTTP 302 Hittades omdirigering: rekommenderas för webbplatser: Omdirigerar en åtgärd till en av de konfigurerade identitetsleverantörer. I dessa fall omdirigeras en webbläsarklient till /.auth/login/<provider> för den provider som du väljer.
HTTP 401 Obehörig: rekommenderas för API:er: Returnerar ett HTTP 401 Unauthorized svar om den anonyma begäran kommer från en intern mobilapp. Du kan också konfigurera avvisandet så att det gäller HTTP 401 Unauthorized för alla begäranden.
HTTP 403 Förbjudet: Konfigurerar avvisandet till att vara HTTP 403 Forbidden för alla begäranden.
HTTP 404 Hittades inte: Konfigurerar avvisandet till för HTTP 404 Not found alla begäranden.

Tokenbutik

App Service tillhandahåller ett inbyggt tokenarkiv. Ett tokenlager är en lagringsplats med token som är associerade med användarna av dina webbappar, API:er eller interna mobilappar. När du aktiverar autentisering med valfri leverantör är det här tokenarkivet omedelbart tillgängligt för din app.

Om programkoden behöver komma åt data från dessa leverantörer för användarens räkning måste du vanligtvis skriva kod för att samla in, lagra och uppdatera dessa token i ditt program. Åtgärderna kan vara:

Publicera till den autentiserade användarens Facebook-tidslinje.
Läs användarens företagsdata med hjälp av Microsoft Graph API.

Med tokenarkivet hämtar du bara token när du behöver dem och uppmanar App Service att uppdatera dem när de blir ogiltiga.

ID-token, åtkomsttoken och uppdateringstoken cachelagras för den autentiserade sessionen. Endast den associerade användaren kan komma åt dem.

Om du inte behöver arbeta med token i din app kan du inaktivera tokenarkivet på appens>.

Loggning och spårning

Om du aktiverar programloggning visas autentiserings- och auktoriseringsspårningar direkt i loggfilerna. Om du ser ett autentiseringsfel som du inte förväntade dig kan du enkelt hitta all information genom att titta i dina befintliga programloggar.

Om du aktiverar spårning av misslyckade förfrågningar kan du se exakt vilken roll autentiserings- och auktoriseringsmodulen kan spela i en misslyckad begäran. Leta efter referenser till en modul med namnet EasyAuthModule_32/64i spårningsloggarna.

Minskning av förfalskning av begäranden mellan webbplatser

App Service-autentisering minskar förfalskningen av begäranden mellan webbplatser genom att granska klientbegäranden efter följande villkor:

Det är en POST begäran som autentiserades via en sessionscookie.
Begäran kom från en känd webbläsare, vilket bestäms av HTTP-huvudet User-Agent .
HTTP- Origin eller HTTP-huvudet Referer saknas eller finns inte i den konfigurerade listan över godkända externa domäner för omdirigering.
HTTP-huvudet Origin saknas eller finns inte i den konfigurerade listan över CORS-ursprung (cross-origin resource sharing).

När en begäran uppfyller alla dessa villkor avvisar App Service-autentisering automatiskt den. Du kan kringgå den här begränsningslogik genom att lägga till din externa domän i omdirigeringslistan i Inställningar>Autentisering>Redigera autentiseringsinställningar>Tillåtna externa omdirigerings-URL:er.

Överväganden för att använda Azure Front Door

När du använder Azure App Service med autentisering bakom Azure Front Door eller andra omvända proxyservrar bör du överväga följande åtgärder.

Inaktivera Azure Front Door-cache

Inaktivera Azure Front Door-cachelagring för autentiseringsarbetsflödet.

Använda Azure Front Door-slutpunkten för omdirigeringar

App Service är vanligtvis inte tillgänglig direkt när den exponeras av Azure Front Door. Du kan till exempel förhindra det här beteendet genom att exponera App Service med hjälp av Azure Private Link i Azure Front Door Premium. Förhindra att autentiseringsarbetsflödet omdirigerar trafik tillbaka till App Service direkt. Mer information finns i Omdirigerings-URI.

Kontrollera att App Service använder rätt omdirigerings-URI

I vissa konfigurationer använder App Service sitt fullständigt kvalificerade domännamn (FQDN) som omdirigerings-URI i stället för Azure Front Door FQDN. Den här konfigurationen orsakar ett problem när klienten omdirigeras till App Service i stället för Azure Front Door. För att ändra det, ställ in forwardProxy till Standard för att få App Service att respektera headern X-Forwarded-Host som Azure Front Door har angett.

Andra omvända proxyservrar, till exempel Azure Application Gateway eller produkter som inte kommer från Microsoft, kan använda olika huvuden och behöver en annan forwardProxy inställning.

Du kan inte ändra konfigurationen forwardProxy med hjälp av Azure-portalen. Du måste använda az rest.

Exportera inställningar

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Uppdateringsinställningar

Sök efter:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Se till att convention är inställt på Standard för att respektera X-Forwarded-Host-huvudet som Azure Front Door använder.

Importinställningar

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Mer information om App Service-autentisering finns i:

Exempel finns i:

Snabbstart: Lägga till appautentisering i webbappen som körs i Azure App Service
Självstudie: Autentisera och auktorisera användare hela vägen i Azure App Service
.NET Core-integrering av Azure AppService Easy Auth (icke-Microsoft GitHub-innehåll)
Få Azure App Service-autentisering att fungera med .NET Core (icke-Microsoft GitHub-innehåll)

Dela via