Dela via

Autentisering och auktorisering i Azure Container Apps

  • Artikel

Azure Container Apps tillhandahåller inbyggda autentiserings- och auktoriseringsfunktioner (kallas ibland "Easy Auth") för att skydda din externa ingressaktiverade containerapp med minimal eller ingen kod.

Mer information om autentisering och auktorisering finns i följande guider för val av leverantör.

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. Det kan dock 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 Container Apps sparar tid och arbete genom att tillhandahålla out-of-the-box-autentisering med federerade identitetsprovidrar. Med de här funktionerna kan du fokusera mer tid på att utveckla ditt program och mindre tid på att skapa säkerhetssystem.

Exempel på fördelar:

  • Azure Container Apps ger åtkomst till olika inbyggda autentiseringsprovidrar.
  • De inbyggda autentiseringsfunktionerna kräver inte något särskilt språk, SDK, säkerhetsexpertis eller ens någon kod som du måste skriva.
  • Du kan integrera med flera leverantörer, inklusive Microsoft Entra-ID, Facebook, Google och X.

Identitetsprovidrar

Container Apps 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 platforma za identitete /.auth/login/aad Microsoft platforma za identitete
Facebook /.auth/login/facebook Facebook
GitHub /.auth/login/github GitHub
Google /.auth/login/google Google
X /.auth/login/x X
Alla OpenID Connect-provider /.auth/login/<providerName> OpenID Connect

När du använder någon av dessa leverantörer är inloggningsslutpunkten tillgänglig för verifiering av användarautentisering och autentiseringstoken från providern. Du kan ge användarna valfritt antal av dessa provideralternativ.

Överväganden för att använda inbyggd autentisering

Den här funktionen ska endast användas med HTTPS. Se till att allowInsecure är inaktiverat i containerappens ingresskonfiguration.

Du kan konfigurera containerappen för autentisering med eller utan att begränsa åtkomsten till webbplatsinnehållet och API:erna. Om du bara vill begränsa appåtkomsten till autentiserade användare anger du inställningen Begränsa åtkomst till Kräv autentisering. Om du vill autentisera men inte begränsa åtkomst anger du inställningen Begränsa åtkomst till Tillåt oautentiserad åtkomst.

Som standard utfärdar varje containerapp sin egen unika cookie eller token för autentisering. Du kan också ange egna signerings- och krypteringsnycklar.

Funktionsarkitektur

Komponenten för mellanprogram för autentisering och auktorisering är en funktion i plattformen som körs som en sidovagnscontainer på varje replik i ditt program. När det är aktiverat hanterar ditt program varje inkommande HTTP-begäran när den har passerat säkerhetsskiktet.

Ett arkitekturdiagram som visar begäranden som fångas upp av en sidovagnscontainer som interagerar med identitetsprovidrar innan trafik tillåts till appcontainern

Plattformsmellanprogrammet hanterar flera saker för din app:

  • Autentiserar användare och klienter med angivna identitetsprovidrar
  • Hanterar den autentiserade sessionen
  • Matar in identitetsinformation i HTTP-begärandehuvuden

Modulen för autentisering och auktorisering körs i en separat container, isolerad från programkoden. Eftersom säkerhetscontainern inte körs i processen går det inte att integrera direkt med specifika språkramverk. Relevant information som din app behöver finns dock i begärandehuvuden enligt beskrivningen i den här artikeln.

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 (serverriktat flöde eller serverflöde): Programmet delegerar federerad inloggning till Container Apps. Delegering är vanligtvis fallet med webbläsarappar, som visar providerns inloggningssida för användaren.

  • Med provider-SDK (klientriktat flöde eller klientflöde): Programmet loggar in användare till providern manuellt och skickar sedan autentiseringstoken till Container Apps för validering. Den här metoden är typisk för webbläsarlösa appar som inte presenterar providerns inloggningssida för användaren. Ett exempel är en intern mobilapp som loggar in användare med hjälp av providerns SDK.

Anrop från en betrodd webbläsarapp i Container Apps till ett annat REST-API i Container Apps kan autentiseras med hjälp av det serverstyrda flödet. Mer information finns i Anpassa inloggning och utloggning.

Tabellen 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 Container Apps lägger till autentiserad cookie som svar. Container Apps 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 Container Apps 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 redigera autentiseringsinställningarna för containerappen för att konfigurera den med olika beteenden när en inkommande begäran inte autentiseras. Följande rubriker beskriver alternativen.

  • Tillåt oautentiserad åtkomst: Det här alternativet defersar auktorisering av oautentiserad trafik till programkoden. För autentiserade begäranden skickar Container Apps även autentiseringsinformation i HTTP-huvudena. Din app kan använda information i rubrikerna för att fatta auktoriseringsbeslut för en begäran.

    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. 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 en 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 Å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

    Som standard kan alla användare i din Microsoft Entra-klientorganisation begära en token för ditt program från Microsoft Entra-ID. Du kan konfigurera appen i Microsoft Entra-ID om du vill begränsa åtkomsten till din app till en definierad uppsättning användare.

Anpassa inloggning och utloggning

Container Apps-autentisering tillhandahåller inbyggda slutpunkter för inloggning och utloggning. När funktionen är aktiverad är dessa slutpunkter tillgängliga under routningsprefixet /.auth i containerappen.

Använda flera inloggningsprovidrar

Portalkonfigurationen erbjuder inte ett nyckelfärdigt sätt att presentera flera inloggningsleverantörer för dina användare (till exempel både Facebook och X). Det är dock inte svårt att lägga till funktionerna i din app. Beskrivning av stegen:

På sidan Autentisering/auktorisering i Azure-portalen konfigurerar du först var och en av identitetsprovidern som du vill aktivera.

I Åtgärd att vidta när begäran inte autentiseras väljer du Tillåt anonyma begäranden (ingen åtgärd).

På inloggningssidan, i navigeringsfältet eller någon annan plats för din app lägger du till en inloggningslänk till var och en av de leverantörer som du har aktiverat (/.auth/login/<provider>). Till exempel:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

När användaren väljer någon av länkarna visas användargränssnittet för respektive providers för användaren.

Om du vill omdirigera användaren efter inloggningen till en anpassad URL använder du frågesträngsparametern post_login_redirect_uri (ska inte förväxlas med omdirigerings-URI:n i konfigurationen av identitetsprovidern). Om du till exempel vill navigera användaren till /Home/Index efter inloggningen använder du följande HTML-kod:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

Klientstyrd inloggning

I en klientstyrd inloggning loggar programmet in användaren till identitetsprovidern med hjälp av ett providerspecifikt SDK. Programkoden skickar sedan den resulterande autentiseringstoken till Container Apps för validering (se autentiseringsflöde) med hjälp av en HTTP POST-begäran.

För att verifiera providertoken måste containerappen först konfigureras med önskad provider. När du har hämtat autentiseringstoken från providern vid körningen publicerar du token för /.auth/login/<provider> validering. Till exempel:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Tokenformatet varierar något beroende på providern. Mer information finns i följande tabell:

Providervärde Krävs i begärandetext Kommentarer
aad {"access_token":"<ACCESS_TOKEN>"} Egenskaperna id_token, refresh_tokenoch expires_in är valfria.
microsoftaccount {"access_token":"<ACCESS_TOKEN>"} eller {"authentication_token": "<TOKEN>" authentication_token föredras framför access_token. Egenskapen expires_in är valfri.
När du begär token från Live-tjänster begär du alltid omfånget wl.basic .
google {"id_token":"<ID_TOKEN>"} Egenskapen authorization_code är valfri. Om du anger ett authorization_code värde läggs en åtkomsttoken och en uppdateringstoken till tokenarkivet. När detta anges authorization_code kan du även eventuellt åtföljas av en redirect_uri egenskap.
facebook {"access_token":"<USER_ACCESS_TOKEN>"} Använd en giltig användaråtkomsttoken från Facebook.
twitter {"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCES_TOKEN_SECRET>"}

Om providertoken har verifierats returnerar API:et med en authenticationToken i svarstexten, vilket är din sessionstoken.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

När du har den här sessionstoken kan du komma åt skyddade appresurser genom att lägga till huvudet i X-ZUMO-AUTH dina HTTP-begäranden. Till exempel:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Logga ut från en session

Användare kan logga ut genom att skicka en GET begäran till appens /.auth/logout slutpunkt. Begäran GET utför följande åtgärder:

  • Rensar cookies för autentisering från den aktuella sessionen.
  • Tar bort den aktuella användarens token från tokenarkivet.
  • Utför en utloggning på serversidan på identitetsprovidern för Microsoft Entra-ID och Google.

Här är en enkel utloggningslänk på en webbsida:

<a href="/.auth/logout">Sign out</a>

Som standard omdirigerar en lyckad utloggning klienten till URL:en /.auth/logout/done. Du kan ändra omdirigeringssidan efter utloggningen genom att lägga till frågeparametern post_logout_redirect_uri . Till exempel:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Se till att koda värdet post_logout_redirect_uriför .

URL:en måste finnas i samma domän när du använder fullständigt kvalificerade URL:er.

Åtkomst till användaranspråk i programkod

För alla språkramverk gör Container Apps anspråken i den inkommande token tillgängliga för programkoden. Anspråken matas in i begärandehuvudena, som finns oavsett om de kommer från en autentiserad slutanvändare eller ett klientprogram. Externa begäranden tillåts inte att ange dessa rubriker, så de finns bara om de anges av Container Apps. Några exempelrubriker är:

  • X-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-ID

Kod som skrivs på valfritt språk eller ramverk kan hämta den information som behövs från dessa rubriker.

Kommentar

Olika språkramverk kan presentera dessa rubriker för appkoden i olika format, till exempel gemener eller rubrikfall.

Nästa steg

Mer information om hur du skyddar containerappen finns i följande artiklar.