Dela via

Autentisering och auktorisering i Azure App Service och Azure Functions

  • Artikel

Kommentar

Från och med den 1 juni 2024 har alla nyligen skapade App Service-appar möjlighet att generera ett unikt standardvärdnamn med hjälp av namngivningskonventionen <app-name>-<random-hash>.<region>.azurewebsites.net. Befintliga appnamn förblir oförändrade.

Exempel: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Mer information finns i Unikt standardvärdnamn för App Service-resurs.

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, X.

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:

Provider Inloggningsslutpunkt Anvisningar
Microsoft Entra /.auth/login/aad App Service Microsoft Entra-plattformsinloggning
Facebook /.auth/login/facebook Facebook-inloggning för App Service
Google /.auth/login/google App Service Google-inloggning
X /.auth/login/x App Service X-inloggning
GitHub /.auth/login/github GitHub-inloggning för App Service
Logga in med Apple /.auth/login/apple App Service-inloggning med Apple-inloggning (förhandsversion)
Alla OpenID Connect-provider /.auth/login/<providerName> App Service OpenID Connect-inloggning

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)."

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

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.

Ett arkitekturdiagram som visar begäranden som fångas upp av en process i webbplatsens sandbox-miljö som interagerar med identitetsprovidrar innan trafik tillåts till den distribuerade platsen

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.

Steg Utan provider-SDK Med provider-SDK
1. Logga in användare 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. Efter autentisering Providern omdirigerar klienten till /.auth/login/<provider>/callback. Klientkod publicerar token från provider till /.auth/login/<provider> för validering.
3. Upprätta autentiserad session App Service lägger till autentiserad cookie som svar. App Service returnerar en egen autentiseringstoken till klientkoden.
4. Servera autentiserat innehåll Klienten inkluderar autentiseringscookie i efterföljande begäranden (hanteras automatiskt av webbläsaren). Klientkoden visar autentiseringstoken i X-ZUMO-AUTH huvudet.

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

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.

I Azure Portal kan du konfigurera App Service med ett antal beteenden när inkommande begäran inte autentiseras. Följande rubriker beskriver alternativen.

Begränsa å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.

Minskning av förfalskning för begäranden mellan webbplatser

App Service-autentisering minskar CSRF genom att granska klientbegäranden efter följande villkor:

  • Det är en POST-begäran som autentiserades med en sessionscookie.
  • Begäran kom från en känd webbläsare (som 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.

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

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

När du använder Azure App Service med autentisering bakom Azure Front Door eller andra omvända proxyservrar måste några ytterligare saker beaktas.

  • 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 .

  • 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.

  • 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 Portal idag 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

Exempel: