Autentisering och auktorisering i Azure App Service och Azure Functions

Azure App Service tillhandahåller inbyggda autentiserings- och auktoriseringsfunktioner (kallas ibland "Enkel autentisering"), så att du kan logga in användare och komma åt data genom att skriva minimal eller ingen kod i webbappen, RESTful API och mobila serverdelen och även Azure Functions. Den här artikeln beskriver hur App Service förenklar autentisering och auktorisering för din app.

Varför ska du använda den inbyggda autentiseringen?

Du behöver inte använda den här funktionen för autentisering och auktorisering. Du kan använda de paketerade säkerhetsfunktionerna i ditt valfritt webbramverk, eller så kan du skriva egna verktyg. Du måste dock se till att din lösning håller sig uppdaterad med de senaste säkerhets-, protokoll- och webbläsaruppdateringarna.

Det kan vara mycket viktigt att implementera en säker lösning för autentisering (inloggningsanvändare) och auktorisering (ge åtkomst till säkra data). Du måste se till att följa branschens bästa praxis och standarder och hålla implementeringen uppdaterad. Den inbyggda autentiseringsfunktionen för 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 Azure App Service kan du integrera en mängd olika autentiseringsfunktioner i webbappen eller API:et utan att implementera dem själv.
• Det är inbyggt direkt i plattformen och kräver inte något särskilt språk, SDK, säkerhetsexpertis eller ens någon kod att använda.
• Du kan integrera med flera inloggningsprovidrar. Till exempel Microsoft Entra, Facebook, Google, Twitter.

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

Identitetsprovidrar

App Service använder federerad identitet, där en identitetsprovider från tredje part hanterar användaridentiteter och autentiseringsflöde åt dig. Följande identitetsprovidrar är tillgängliga som standard:

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 den här funktionen omdirigeras alla begäranden till ditt program automatiskt till HTTPS, oavsett apptjänstkonfigurationsinställningen för att framtvinga HTTPS. Du kan inaktivera detta med inställningen requireHttps i V2-konfigurationen. Vi rekommenderar dock att du håller dig till HTTPS, och du bör se till att inga säkerhetstoken någonsin överförs via icke-säkra HTTP-anslutningar.

App Service kan användas för autentisering med eller utan att begränsa åtkomsten till webbplatsens innehåll och API:er. Åtkomstbegränsningar kan anges i avsnittet Inställningar för autentiseringsautentisering> i webbappen. Om du bara vill begränsa appåtkomsten till 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)."

Så här fungerar det

Funktionsarkitektur

Autentiseringsflöde

Auktoriseringsbeteende

Tokenarkiv

Loggning och spårning

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 den är aktiverad skickar varje inkommande HTTP-begäran igenom den innan den hanteras av ditt program.

Plattformsmellanprogrammet hanterar flera saker för din app:

• Autentiserar användare och klienter med angivna identitetsproviders
• Validerar, lagrar och uppdaterar OAuth-token som utfärdats av de konfigurerade identitetsproviders
• Hanterar den autentiserade sessionen
• Matar in identitetsinformation i HTTP-begärandehuvuden

Modulen körs separat från programkoden och kan konfigureras 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 den är aktiverad skickar varje inkommande HTTP-begäran igenom den innan den hanteras av ditt program.

Funktionsarkitektur i Linux och containrar

Modulen för autentisering och auktorisering körs i en separat container, isolerad från programkoden. Med hjälp av det så kallade ambassadörsmönstret interagerar det 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 med hjälp av begärandehuvuden enligt beskrivningen nedan.

Autentiseringsflöde

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

• Utan provider-SDK: Programmet delegerar federerad inloggning till App Service. Detta är vanligtvis fallet med webbläsarappar, som kan presentera leverantörens 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 och skickar sedan autentiseringstoken till App Service för validering. Detta ä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 samt 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 med hjälp av det serverriktade flödet. Mer information finns i Anpassa inloggningar och utloggningar.

Tabellen nedan visar stegen i autentiseringsflödet.

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 ett antal beteenden när inkommande begäran inte autentiseras. Följande rubriker beskriver alternativen.

Restrisk åtkomst

• Tillåt oautentiserade begäranden Det här alternativet defersar auktorisering av oautentiserad trafik till programkoden. 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 .

  Med det här alternativet behöver du inte skriva någon autentiseringskod i din app. Finare auktorisering, till exempel rollspecifik auktorisering, kan hanteras genom att granska användarens anspråk (se Åtkomstanspråk för användare).

  Varning

  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.

  Kommentar

  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.

Oautentiserade begäranden

• HTTP 302 Hittad omdirigering: rekommenderas för åtgärden Omdirigering av webbplatser till en av de konfigurerade identitetsprovidrar. 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 Om den anonyma begäran kommer från en intern mobilapp är det returnerade svaret en HTTP 401 Unauthorized. Du kan också konfigurera avvisandet som ett HTTP 401 Unauthorized för alla begäranden.
• HTTP 403 Förbjudet Konfigurerar avvisandet som ett HTTP 403 Forbidden för alla begäranden.
• HTTP 404 Det går inte att hitta Konfigurerar avvisandet som ett HTTP 404 Not found för alla begäranden.

Tokenarkiv

App Service tillhandahåller ett inbyggt tokenarkiv, som ä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 din programkod behöver komma åt data från dessa leverantörer för användarens räkning, till exempel:

• inlägg på den autentiserade användarens Facebook-tidslinje
• läsa användarens företagsdata med hjälp av Microsoft Graph API

Du måste vanligtvis skriva kod för att samla in, lagra och uppdatera dessa token i ditt program. 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 och de är endast tillgängliga för den associerade användaren.

Om du inte behöver arbeta med token i din app kan du inaktivera tokenarkivet på appens autentiserings-/auktoriseringssida.

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 ha spelat i en misslyckad begäran. Leta efter referenser till en modul med namnet EasyAuthModule_32/64i spårningsloggarna.

Att tänka på när du använder Azure Front Door

När du använder Azure App Service med Easy Auth bakom Azure Front Door eller andra omvända proxyservrar måste du ta hänsyn till några ytterligare saker.

1. Inaktivera Cachelagring för autentiseringsarbetsflödet

   Mer information om hur du konfigurerar regler i Azure Front Door för att inaktivera cachelagring för autentiserings- och auktoriseringsrelaterade sidor finns i Inaktivera cache för autentiseringsarbetsflöde .

2. Använd Front Door-slutpunkten för omdirigeringar

   App Service är vanligtvis inte tillgänglig direkt när den exponeras via Azure Front Door. Detta kan till exempel förhindras genom att exponera App Service via Private Link i Azure Front Door Premium. För att förhindra att autentiseringsarbetsflödet omdirigerar trafik tillbaka till App Service direkt är det viktigt att konfigurera programmet att omdirigera tillbaka till https://<front-door-endpoint>/.auth/login/<provider>/callback.

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

   I vissa konfigurationer använder App Service FQDN för App Service som omdirigerings-URI i stället för Front Door FQDN. Detta leder till ett problem när klienten omdirigeras till App Service i stället för Front Door. Om du vill ändra det forwardProxy måste inställningen anges till Standard så att App Service respekterar X-Forwarded-Host huvudet som angetts av Azure Front Door.

   Andra omvända proxyservrar som Azure Application Gateway eller produkter från tredje part kan använda olika rubriker och behöver en annan forwardProxy-inställning.

   Den här konfigurationen kan inte utföras via Azure-portalen i dag och måste göras via 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"
     }
   }
   

   och se till att convention är inställd på att Standard respektera huvudet X-Forwarded-Host som används av Azure Front Door.

   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

Fler resurser

• Anvisningar: Konfigurera din App Service- eller Azure Functions-app så att den använder Microsoft Entra-inloggning
• Anpassa inloggningar och utloggningar

• Arbeta med OAuth-token och sessioner
• Åtkomst till användar- och programanspråk
• Filbaserad konfiguration

Exempel:

• Självstudie: Lägga till autentisering i din webbapp som körs i Azure App Service
• Självstudie: Autentisera och auktorisera användare från slutpunkt till slutpunkt i Azure App Service (Windows eller Linux)
• .NET Core-integrering av Azure AppService EasyAuth (tredje part)
• Få Azure App Service-autentisering att fungera med .NET Core (tredje part)