Anpassa inloggning och utloggning i Azure App Service-autentisering

  • Artikel

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

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 Twitter). 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/twitter">Log in with Twitter</a>
<a href="/.auth/login/apple">Log in with Apple</a>

När användaren klickar på någon av länkarna öppnas respektive inloggningssida för att logga in 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 App Service för validering (se autentiseringsflöde) med hjälp av en HTTP POST-begäran. Den här valideringen ger dig inte åtkomst till önskade appresurser, men en lyckad validering ger dig en sessionstoken som du kan använda för att komma åt appresurser.

För att verifiera providertoken måste App Service-appen 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://<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. 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":"<access_token_secret>"}

Kommentar

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

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://<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 gör följande:

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

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 post_logout_redirect_uriför .

När du använder fullständigt kvalificerade URL:er måste URL:en antingen finnas i samma domän eller konfigureras som en tillåten extern omdirigerings-URL för din app. I följande exempel om du vill omdirigera till https://myexternalurl.com 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 navigera 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 över OAuth-inloggningen. Det gör du genom att ange en appinställning med namnet WEBSITE_AUTH_PRESERVE_URL_FRAGMENT .true Du kan göra det i Azure-portalen eller helt enkelt köra följande kommando i Azure Cloud Shell:

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

Begränsa domänen för inloggningskonton

Med både Microsoft-konto och Microsoft Entra-ID kan du logga in från flera domäner. Till exempel tillåter Microsoft-konto outlook.com, live.com och hotmail.com konton. Microsoft Entra-ID tillåter valfritt antal anpassade domäner för inloggningskontona. Men du kanske vill påskynda användarna 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 https://resources.azure.comLäs/skriv överst på sidan i .

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

  3. Klicka på Redigera.

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

    "identityProviders": {
    "azureActiveDirectory": {
        "login": {
            "loginParameters": ["domain_hint=<domain-name>"],
        }
    }
}

  5. Klicka på Lägg till.

Den här inställningen lägger till frågesträngsparametern domain_hint 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 den inte en säkerhetsfunktion.

Auktorisera eller neka användare

Medan App Service tar hand om det enklaste auktoriseringsfallet (dvs. avvisa oautentiserade begäranden), kan din app kräva mer detaljerade auktoriseringsbeteenden, till exempel att begränsa åtkomsten till endast en viss grupp användare. I vissa fall måste du skriva anpassad programkod för att tillåta eller neka åtkomst till den inloggade användaren. I andra 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 redigera filen Web.config . Linux-appar använder inte IIS och kan inte konfigureras via Web.config.

  1. Navigera till https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. I webbläsarutforskaren för apptjänstfilerna går du till plats/wwwroot. Om det inte finns någon Web.config skapar du den genom att+> välja Ny fil.

  3. Välj pennan för Web.config för att redigera den. Lägg till följande konfigurationskod och klicka på 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>

Identitetsprovidernivå

Identitetsprovidern kan ge viss nyckelnyckelauktorisering. Till exempel:

Programnivå

Om någon av de andra nivåerna inte ger den auktorisering 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.

Fler resurser