Autentisering och auktorisering i Azure App Service och Azure Functions
Azure App Service har 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 din webbapp, 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 jag 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 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 inbyggd autentisering med federerade identitetsproviders, så att du kan fokusera på resten av ditt program.
- Azure App Service kan du integrera en mängd olika autentiseringsfunktioner i din webbapp eller ditt API 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 inloggningsproviders. Till exempel Azure AD, Facebook, Google och Twitter.
Identitetsprovidrar
App Service använder federeradidentitet , där en tredjeparts-identitetsprovider hanterar användaridentiteter och autentiseringsflödet åt dig. Följande identitetsproviders är tillgängliga som standard:
| Leverantör | Inloggningsslutpunkt | How-To vägledning |
|---|---|---|
| Microsoft Identity Platform | /.auth/login/aad |
App Service för Microsoft Identity Platform |
/.auth/login/facebook |
App Service Facebook-inloggning | |
/.auth/login/google |
App Service Google-inloggning | |
/.auth/login/twitter |
App Service Twitter-inloggning | |
| Valfri OpenID-Anslut provider | /.auth/login/<providerName> |
App Service OpenID Anslut inloggning |
När du aktiverar autentisering och auktorisering med någon av dessa providers är inloggningsslutpunkten tillgänglig för användarautentisering och för validering av autentiseringstoken från providern. Du kan ge användarna val av 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 vilken konfigurationsinställning App Service använder 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 överförs över 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. Om du vill begränsa appåtkomsten till endast autentiserade användare anger du Åtgärd att vidta när begäran inte har autentiserats för att logga in med någon av de konfigurerade identitetsproviders. Om du vill autentisera men inte begränsa åtkomsten anger du Åtgärd som ska vidtas när begäran inte autentiseras till "Tillåt anonyma begäranden (ingen åtgärd)."
Anteckning
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 distributionsfack. När du testar ny kod kan den här praxis hjälpa till att förhindra att problem påverkar produktionsappen.
Så här fungerar det
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.
Plattformens mellanprogram hanterar flera saker för din app:
- Autentiserar användare och klienter med de angivna identitetsprovider(erna)
- 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 eller med hjälp av en konfigurationsfil. Inga SDK:er, specifika programmeringsspråk eller ändringar i programkoden krävs.
Funktionsarkitektur på Windows (icke-containerdistribution)
Autentiserings- och auktoriseringsmodulen körs som en intern 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
Autentiserings- och auktoriseringsmodulen körs i en separat container, isolerad från programkoden. Med hjälp av det som kallas ambassadörsmönsterinteragerar den med inkommande trafik för att utföra liknande funktioner som på 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 genom med hjälp av begärandehuvuden enligt förklaringen nedan.
Autentiseringsflöde
Autentiseringsflödet är detsamma för alla providers, 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 visa leverantörens inloggningssida för användaren. Serverkoden hanterar inloggningsprocessen, så den kallas även för server dirigerat flöde eller serverflöde. Det här fallet gäller för webbläsarappar. Det gäller även för interna appar som loggar in användare med Mobile Apps-klient-SDK eftersom SDK öppnar en webbvy för att logga in användare med App Service 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äsarbaserade appar som inte kan visa leverantörens inloggningssida för användaren. Programkoden hanterar inloggningsprocessen, så den kallas även för klient dirigerat flöde eller klientflöde. Det här fallet gäller för 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 leverantörens SDK.
Anrop från en betrodd webbläsarapp i App Service till en annan REST API i App Service eller Azure Functions kan autentiseras med hjälp av det serverbaserade flödet. Mer information finns i Anpassa inloggningar och ut inloggningar.
I tabellen nedan visas 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. Efterautentisering | Providern omdirigerar klienten till /.auth/login/<provider>/callback . |
Klientkoden skickar token från providern till för /.auth/login/<provider> validering. |
| 3. Upprätta autentiserad session | App Service lägger till autentiserad cookie för svar. | App Service sin egen autentiseringstoken till klientkoden. |
| 4. Betjäna autentiserat innehåll | Klienten inkluderar autentiseringscookie i efterföljande begäranden (hanteras automatiskt av webbläsaren). | Klientkod presenterar autentiseringstoken X-ZUMO-AUTH i sidhuvud (hanteras automatiskt Mobile Apps klient-SDK:er). |
För klientwebbläsare App Service automatiskt dirigera alla oauticerade användare till /.auth/login/<provider> . Du kan också ge användarna en eller flera /.auth/login/<provider> länkar för att logga in på din app med valfri leverantör.
Auktoriseringsbeteende
I Azure Portalkan du konfigurera App Service med ett antal beteenden när inkommande begäran inte autentiseras. Följande rubriker beskriver alternativen.
Tillåt oauthenticerade begäranden
Det här alternativet skjuter upp auktorisering av oauticerad trafik till din programkod. För autentiserade begäranden skickar App Service även vidare 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 oauticerad trafik till ditt program. Det här avvisandet kan vara en omdirigeringsåtgärd till en av de konfigurerade identitetsprovidersen. 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 inbyggd mobilapp är det returnerade svaret en HTTP 401 Unauthorized . Du kan också konfigurera avvisningen till 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. Finer auktorisering, till exempel rollspecifik auktorisering, kan hanteras genom att granska användarens anspråk (se Åtkomst till användaranspråk).
Varning
Begränsning av åtkomst 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
Som standard kan alla användare i din Azure AD-klientorganisation begära en token för ditt program från Azure AD. Du kan konfigurera programmet i Azure AD om du vill begränsa åtkomsten till din app till en definierad uppsättning användare.
Tokenarkiv
App Service 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 blir det här tokenarkivet omedelbart tillgängligt för din app. Om din programkod behöver åtkomst till data från dessa providers för användarens räkning, till exempel:
- publicera på den autentiserade användarens Facebook-tidslinje
- läsa användarens företagsdata med hjälp av Microsofts 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 säger till App Service 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 sida autentisering/auktorisering.
Loggning och spårning
Om du aktiverar programloggningvisas 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ågningarkan du se exakt vilken roll autentiserings- och auktoriseringsmodulen kan ha spelat i en misslyckad begäran. Leta efter referenser till en modul med namnet i spårningsloggarna. EasyAuthModule_32/64
Fler resurser
- Så här konfigurerar du din App Service eller Azure Functions för att använda Azure AD-inloggning
- Anpassa inloggningar och ut logga ut
- Arbeta med OAuth-token och -sessioner
- Få åtkomst till användar- och programanspråk
- Filbaserad konfiguration
Prover:
- Självstudie: Lägga till autentisering i webbappen som körs Azure App Service
- Självstudie: Autentisera och auktorisera användare från Azure App Service (Windows eller Linux)
- .NET Core-integrering av Azure AppService EasyAuth (tredje part)
- Få Azure App Service autentisering som fungerar med .NET Core (tredje part)