Autentisering och auktorisering i Azure App Service och Azure Functions

  • Artikel
  • 9 minuter för att läsa

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

Varför ska man 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 webbramverk eller skriva egna verktyg. Du måste dock se till att din lösning är uppdaterad med de senaste säkerhets-, protokoll- och webbläsaruppdateringarna.

Det kan ta mycket tid 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. Med den inbyggda autentiseringsfunktionen för App Service och Azure Functions kan du spara tid och arbete genom att tillhandahålla färdig autentisering med federerade identitetsprovidrar så att du kan fokusera på resten av programmet.

  • 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 Azure AD, Facebook, Google, Twitter.

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:

Leverantör Inloggningsslutpunkt How-To vägledning
Microsoft identitetsplattform /.auth/login/aad App Service Microsoft Identity Platform-inloggning
Facebook /.auth/login/facebook App Service Facebook-inloggning
Google /.auth/login/google App Service Google-inloggning
Twitter /.auth/login/twitter App Service Twitter-inloggning
GitHub /.auth/login/github App Service GitHub-inloggning
Logga in med Apple /.auth/login/apple App Service Logga in med Apple-inloggning (förhandsversion)
Valfri OpenID Connect-provider /.auth/login/<providerName> App Service OpenID Connect-inloggning

När du konfigurerar den här funktionen med någon av dessa providrar ä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.

Att tänka på när du använder inbyggd autentisering

Om du aktiverar den här funktionen omdirigeras alla begäranden till ditt program automatiskt till HTTPS, oavsett App Service konfigurationsinställningen framtvingar HTTPS. Du kan inaktivera detta med requireHttps inställningen 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 webbplatsinnehåll och API:er. 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 sin egen behörighet och sitt medgivande. Undvik behörighetsdelning mellan miljöer genom att använda separata appregistreringar för separata distributionsplatser. När du testar ny kod kan den här metoden förhindra att problem påverkar produktionsappen.

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 passerar 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
  • Verifierar, 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 (icke-containerdistribution)

Modulen för autentisering och auktorisering körs som en inbyggd IIS-modul i samma sandbox-miljö som ditt program. När den är aktiverad passerar 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 via begärandehuvudena enligt beskrivningen nedan.

Autentiseringsflöde

Autentiseringsflödet är detsamma för alla leverantörer, men varierar 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 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 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 providerns 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 serverstyrda 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. Klientkoden publicerar token från providern till /.auth/login/<provider> för validering.
3. Upprätta autentiserad session App Service lägger till autentiserad cookie som svar. App Service returnerar sin egen autentiseringstoken till klientkoden.
4. Hantera autentiserat innehåll Klienten innehåller autentiseringscookie i efterföljande begäranden (hanteras automatiskt av webbläsaren). Klientkoden presenterar autentiseringstoken i X-ZUMO-AUTH sidhuvudet.

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

Auktoriseringsbeteende

Viktigt

Som standard ger 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.

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 inloggningsproviders 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. Det här avvisandet kan vara en omdirigeringsåtgärd till en av de konfigurerade identitetsprovidrar. I dessa fall omdirigeras en webbläsarklient till /.auth/login/<provider> för den leverantör du väljer. Om den anonyma begäran kommer från en intern mobilapp är det returnerade svaret ett HTTP 401 Unauthorized. Du kan också konfigurera avvisandet så att det är en HTTP 401 Unauthorized eller HTTP 403 Forbidden för alla 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 Åtkomst till användaranspråk).

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.

Anteckning

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

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 provider ä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, till exempel:

  • publicera till 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 tokens 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 modulen för autentisering och auktorisering 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 cachelagring för autentiseringsarbetsflöden .

  2. Använda 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 App Service FQDN som omdirigerings-URI i stället för det fullständiga domännamnet för Front Door. 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 huvuden och behöver en annan forwardProxy-inställning.

    Den här konfigurationen kan inte göras via Azure Portal i dag och måste göras via az rest:

    Exportinstä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 Standard att convention är inställt på att respektera huvudet X-Forwarded-Host som används av Azure Front Door.

    Importera 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 put --body @auth.json

Fler resurser

Prover: