Utforska autentisering och auktorisering i App Service
Azure App Service tillhandahåller inbyggd autentisering och auktoriseringsstöd. Du kan logga in användare och komma åt data genom att skriva minimal eller ingen kod i webbappen, RESTful API, mobil serverdelen eller Azure Functions.
Varför ska du använda den inbyggda autentiseringen?
Du behöver inte använda App Service för autentisering och auktorisering. Många webbramverk är paketerade med säkerhetsfunktioner och du kan använda dem om du vill. Om du behöver mer flexibilitet än vad App Service tillhandahåller kan du också skriva egna verktyg.
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 olika autentiseringsfunktioner i webbappen eller API:et utan att implementera dem själv.
- Autentisering är inbyggt direkt i plattformen och kräver inte något särskilt språk, SDK, säkerhetsexpertis eller kod.
- Du kan integrera med flera inloggningsprovidrar. Till exempel Microsoft Entra ID, Facebook, Google, X.
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-identitetsplattform | /.auth/login/aad |
App Service-Microsofts identitetsplattform inloggning |
/.auth/login/facebook |
Facebook-inloggning för App Service | |
/.auth/login/google |
App Service Google-inloggning | |
| X | /.auth/login/twitter |
App Service X-inloggning |
| Alla OpenID Connect-provider | /.auth/login/<providerName> |
App Service OpenID Connect-inloggning |
| GitHub | /.auth/login/github |
GitHub-inloggning för App Service |
När du aktiverar autentisering och auktorisering 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.
Hur det fungerar
Modulen för autentisering och auktorisering körs i samma sandbox-miljö som programkoden. När den är aktiverad skickas varje inkommande HTTP-begäran genom den innan den överlämnas till din programkod. Den här modulen hanterar flera saker för din app:
- Autentiserar användare och klienter med den angivna identitetsprovidern
- Validerar, lagrar och uppdaterar OAuth-token som utfärdats av den konfigurerade identitetsprovidern
- 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.
Kommentar
I Linux och containrar körs autentiserings- och auktoriseringsmodulen i en separat container, isolerad från programkoden. Eftersom den inte körs i processen går det inte att integrera direkt med specifika språkramverk.
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. Den här delegeringen är vanligtvis fallet med webbläsarappar, som kan presentera leverantörens inloggningssida för användaren. Serverkoden hanterar inloggningsprocessen och kallas för serverstyrt flöde eller serverflöde.
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 och kallas för klientstyrt flöde eller klientflöde. Detta gäller rest-API:er, Azure Functions, JavaScript-webbläsarklienter och interna mobilappar som loggar in användare med providerns SDK.
I följande tabell visas stegen i autentiseringsflödet.
| Steg | Utan provider-SDK | Med provider-SDK |
|---|---|---|
| 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. |
| Efter autentisering | Providern omdirigerar klienten till /.auth/login/<provider>/callback. |
Klientkod publicerar token från provider till /.auth/login/<provider> för validering. |
| Upprätta autentiserad session | App Service lägger till autentiserad cookie som svar. | App Service returnerar en egen autentiseringstoken till klientkoden. |
| Hantera autentiserat innehåll | Klienten inkluderar autentiseringscookie i efterföljande begäranden (hanteras automatiskt av webbläsaren). | Klientkoden visar autentiseringstoken i X-ZUMO-AUTH huvudet (hanteras automatiskt av Mobile Apps-klient-SDK:er). |
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 Portal kan du konfigurera App Service med många beteenden när en inkommande begäran inte autentiseras.
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. Med den kan du presentera flera inloggningsleverantörer för dina användare.
Kräv autentisering: Det här alternativet avvisar all oautentiserad trafik till ditt program. Detta avvisande 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 provider som du väljer. Om den anonyma begäran kommer från en intern mobilapp är det returnerade svaret enHTTP 401 Unauthorized. Du kan också konfigurera avvisandet så att det är enHTTP 401 UnauthorizedellerHTTP 403 Forbiddenför alla begäranden.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.
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.
Loggning och spårning
Om du aktiverar programloggning samlas autentiserings- och auktoriseringsspårningar in direkt i dina loggfiler. 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.