Dela via


Anpassa inloggningar och utloggningar i Azure App Service-autentisering

Den här artikeln visar hur du anpassar användarinloggningar och utloggningar när du använder den inbyggda autentiseringen och auktoriseringen i Azure App Service.

Använda flera inloggningsprovidrar

Konfigurationen av Azure-portalen erbjuder inte ett nyckelfärdigt sätt att presentera flera inloggningsleverantörer för dina användare. Du kanske till exempel vill erbjuda både Facebook och X som alternativ. Så här lägger du till flera inloggningsleverantörer i din app:

  1. I Azure-portalen går du till webbappen och väljer Inställningar>Autentisering.

  2. För Autentiseringsinställningar väljer du Redigera.

  3. För Begränsa åtkomst väljer du Tillåt oautentiserad åtkomst.

  4. På inloggningssidan, navigeringsfältet eller någon annan plats i 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 Microsoft Entra</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>
    <a href="/.auth/login/apple">Log in with Apple</a>
    

När användaren väljer någon av länkarna öppnas respektive sida för inloggning.

Om du vill omdirigera användaren till en anpassad URL efter inloggningen använder du frågesträngsparametern post_login_redirect_uri . Om du till exempel vill flytta 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>

Anteckning

Blanda inte ihop det här värdet med omdirigerings-URI:n i konfigurationen av identitetsprovidern.

Använda klientstyrd inloggning

I en klientstyrd inloggning loggar programmet in användaren till identitetsprovidern med hjälp av en providerspecifik SDK. Programkoden skickar sedan den resulterande autentiseringstoken till App Service för validering med hjälp av en HTTP-begäran POST . Den här valideringen ger inte användarna åtkomst till önskade appresurser. En lyckad validering ger användarna en sessionstoken som de kan använda för att komma åt appresurser. Mer information finns i Autentiseringsflöde.

För att verifiera providertoken måste App Service-appen först konfigureras med önskad provider. När du vid körning har hämtat autentiseringstoken från din leverantör, skickar du token till /.auth/login/<provider> för validering. Till exempel:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

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

Tokenformatet varierar något beroende på providern:

Leverantörsvärde Krävs i begärandetext Kommentarer
aad {"access_token":"<access_token>"} Egenskaperna id_token, refresh_tokenoch expires_in är valfria.
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 du anger authorization_codekan du eventuellt bifoga den med 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":"<access_token_secret>"}

Anteckning

GitHub-providern för App Service-autentisering stöder inte anpassad inloggning och utloggning.

Om providertoken har verifierats returnerar API:et med ett authenticationToken värde i svarstexten. Det här värdet är din sessionstoken. För mer information om användaranspråk, se Arbeta med användaridentiteter i Azure App Service-autentisering.

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

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

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Logga ut från en session

Användare kan initiera en utloggning genom att skicka en GET begäran till appens /.auth/logout slutpunkt. Begäran GET :

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

Vi rekommenderar att du kodar värdet av post_logout_redirect_uri.

När du använder fullständigt kvalificerade URL:er måste URL:en finnas i samma domän eller konfigureras som en tillåten extern omdirigerings-URL för din app. I följande exempel omdirigeras till en https://myexternalurl.com URL som inte finns i samma domän:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Kör följande kommando i Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Bevara URL-fragment

När användarna har loggat in på din app vill de vanligtvis omdirigeras till samma avsnitt på samma sida, till exempel /wiki/Main_Page#SectionZ. Men eftersom URL-fragment (till exempel #SectionZ) aldrig skickas till servern bevaras de inte som standard när OAuth-inloggningen har slutförts och omdirigeras tillbaka till din app. Användarna får sedan en suboptimal upplevelse när de behöver gå till önskad fästpunkt igen. Den här begränsningen gäller för alla autentiseringslösningar på serversidan.

I App Service-autentisering kan du bevara URL-fragment i OAuth-inloggningen genom att ange WEBSITE_AUTH_PRESERVE_URL_FRAGMENT till true. Du använder den här appinställningen i Azure-portalen, eller så kan du köra följande kommando i Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Ange domäntipset för inloggningskonton

Både Microsoft-konton och Microsoft Entra låter användare logga in från flera domäner. Ett Microsoft-konto tillåter outlook.com, live.com och hotmail.com-konton. Microsoft Entra tillåter valfritt antal anpassade domäner för inloggningskontona. Men du kanske vill snabbt leda dina användare direkt till din egen Microsoft Entra-inloggningssida (till exempel contoso.com).

Följ dessa steg för att föreslå domännamnet för inloggningskontona:

  1. Välj Läs/skriv längst upp på sidan i Resursutforskaren.

  2. I den vänstra panelen går du till prenumerationer>prenumerationsnamn>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2.

  3. Välj Redigera.

  4. Lägg till en loginParameters matris med ett domain_hint objekt:

    "identityProviders": {
        "azureActiveDirectory": {
            "login": {
                "loginParameters": ["domain_hint=<domain-name>"],
            }
        }
    }
    
  5. Välj Placera.

Den här inställningen lägger till domain_hint frågesträngsparametern i url:en för inloggningsomdirigering.

Viktigt!

Det är möjligt för klienten att ta bort parametern domain_hint efter att ha tagit emot omdirigerings-URL:en och sedan logga in med en annan domän. Så även om den här funktionen är praktisk är det inte en säkerhetsfunktion.

Auktorisera eller neka användare

App Service tar hand om det enklaste auktoriseringsfallet, till exempel avvisa oautentiserade begäranden. Din app kan kräva mer detaljerade auktoriseringsbeteenden, till exempel att begränsa åtkomsten till endast en viss grupp användare.

Du kan behöva skriva anpassad programkod för att tillåta eller neka åtkomst till den inloggade användaren. I vissa fall kanske App Service eller din identitetsprovider kan hjälpa till utan att kräva kodändringar.

Servernivå (endast Windows-appar)

För alla Windows-appar kan du definiera auktoriseringsbeteendet för IIS-webbservern genom att web.config redigera filen. Linux-appar använder inte IIS och kan inte konfigureras via web.config.

  1. Om du vill gå till Kudu-felsökningskonsolen för din app väljer du Utvecklingsverktyg>Avancerade verktyg och väljer . Välj sedan Felsökningskonsol.

    Du kan också öppna den här sidan med den här URL:en: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole. Om du vill hämta värdena för slumpmässig hash och region kopierar du Standarddomän i appen Översikt.

  2. I webbläsarutforskaren för dina App Service-filer går du till site/wwwroot. Om web.config det inte finns skapar du det genom att +> välja Ny fil.

  3. Välj pennan för web.config att redigera filen. Lägg till följande konfigurationskod och välj sedan Spara. Om web.config redan finns lägger du bara till elementet <authorization> med allt i det. Lägg till de konton som du vill tillåta i elementet <allow> .

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
       <system.web>
          <authorization>
            <allow users="user1@contoso.com,user2@contoso.com"/>
            <deny users="*"/>
          </authorization>
       </system.web>
    </configuration>
    

Nivå för identitetsutfärdare

Identitetsleverantören kan ge viss färdig auktorisering. Till exempel:

Programnivå

Om någon av de andra nivåerna inte ger den auktorisering som du behöver, eller om din plattform eller identitetsprovider inte stöds, måste du skriva anpassad kod för att auktorisera användare baserat på användaranspråken.