Aanmelden en afmelden aanpassen Azure-app Serviceverificatie

  • Artikel

In dit artikel leest u hoe u aanmeldingen en afmeldingen van gebruikers kunt aanpassen met behulp van de ingebouwde verificatie en autorisatie in App Service.

Meerdere aanmeldingsproviders gebruiken

De portalconfiguratie biedt geen kant-en-klare manier om meerdere aanmeldingsproviders aan uw gebruikers te presenteren (zoals Facebook en Twitter). Het is echter niet moeilijk om de functionaliteit aan uw app toe te voegen. De stappen zijn als volgt:

Configureer eerst op de pagina Verificatie/autorisatie in Azure Portal elk van de id-provider die u wilt inschakelen.

Selecteer anonieme aanvragen toestaan (geen actie) in Actie die moet worden uitgevoerd wanneer de aanvraag niet is geverifieerd.

Voeg op de aanmeldingspagina of de navigatiebalk of een andere locatie van uw app een aanmeldingskoppeling toe aan alle providers die u hebt ingeschakeld (/.auth/login/<provider>). Voorbeeld:

<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>

Wanneer de gebruiker op een van de koppelingen klikt, wordt de desbetreffende aanmeldingspagina geopend om de gebruiker aan te melden.

Als u de gebruiker na aanmelding wilt omleiden naar een aangepaste URL, gebruikt u de post_login_redirect_uri querytekenreeksparameter (niet te verwarren met de omleidings-URI in de configuratie van uw id-provider). Als u bijvoorbeeld door de gebruiker /Home/Index wilt navigeren nadat u zich hebt aangemeld, gebruikt u de volgende HTML-code:

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

Door de client gerichte aanmelding

In een clientgestuurde aanmelding meldt de toepassing de gebruiker aan bij de id-provider met behulp van een providerspecifieke SDK. De toepassingscode verzendt vervolgens het resulterende verificatietoken naar App Service voor validatie (zie verificatiestroom) met behulp van een HTTP POST-aanvraag. Deze validatie zelf verleent u geen toegang tot de gewenste app-resources, maar een geslaagde validatie geeft u een sessietoken dat u kunt gebruiken om toegang te krijgen tot app-resources.

Om het providertoken te valideren, moet de App Service-app eerst worden geconfigureerd met de gewenste provider. Nadat u tijdens runtime het verificatietoken van uw provider hebt opgehaald, plaatst u het token op /.auth/login/<provider> voor validatie. Voorbeeld:

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

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

De tokenindeling varieert enigszins afhankelijk van de provider. Zie de volgende tabel voor meer informatie:

Providerwaarde Vereist in aanvraagbody Opmerkingen
aad {"access_token":"<access_token>"} De id_token, refresh_tokenen expires_in eigenschappen zijn optioneel.
microsoftaccount {"access_token":"<access_token>"} of {"authentication_token": "<token>" authentication_token heeft de voorkeur boven access_token. De expires_in eigenschap is optioneel.
Wanneer u het token aanvraagt bij liveservices, vraagt u altijd het wl.basic bereik aan.
google {"id_token":"<id_token>"} De authorization_code eigenschap is optioneel. Als u een authorization_code waarde opgeeft, worden er een toegangstoken en een vernieuwingstoken toegevoegd aan het tokenarchief. Indien opgegeven, authorization_code kan ook eventueel worden vergezeld door een redirect_uri accommodatie.
facebook {"access_token":"<user_access_token>"} Gebruik een geldig toegangstoken voor gebruikers van Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Notitie

De GitHub-provider voor App Service-verificatie biedt geen ondersteuning voor aangepaste aanmelding en afmelding.

Als het providertoken is gevalideerd, retourneert de API een authenticationToken in de antwoordtekst. Dit is uw sessietoken.

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

Zodra u dit sessietoken hebt, hebt u toegang tot beveiligde app-resources door de X-ZUMO-AUTH header toe te voegen aan uw HTTP-aanvragen. Voorbeeld:

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

Afmelden bij een sessie

Gebruikers kunnen een afmelding initiëren door een GET aanvraag naar het eindpunt van /.auth/logout de app te verzenden. De GET aanvraag doet het volgende:

  • Hiermee worden verificatiecookies van de huidige sessie gewist.
  • Hiermee verwijdert u de tokens van de huidige gebruiker uit het tokenarchief.
  • Voor Microsoft Entra ID en Google voert u een afmelding aan de serverzijde uit bij de id-provider.

Dit is een voorbeeld van een eenvoudige afmeldingskoppeling op een webpagina:

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

Standaard leidt een geslaagde afmelding de client om naar de URL /.auth/logout/complete. U kunt de omleidingspagina voor afmelden wijzigen door de post_logout_redirect_uri queryparameter toe te voegen. Voorbeeld:

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

Het is raadzaam om de waarde van post_logout_redirect_uri.

Wanneer u volledig gekwalificeerde URL's gebruikt, moet de URL worden gehost in hetzelfde domein of worden geconfigureerd als een toegestane externe omleidings-URL voor uw app. In het volgende voorbeeld kunt u omleiden naar https://myexternalurl.com die niet in hetzelfde domein:

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

Voer de volgende opdracht uit in Azure Cloud Shell:

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

URL-fragmenten behouden

Nadat gebruikers zich hebben aangemeld bij uw app, willen ze meestal worden omgeleid naar dezelfde sectie van dezelfde pagina, zoals /wiki/Main_Page#SectionZ. Omdat URL-fragmenten (bijvoorbeeld#SectionZ) nooit naar de server worden verzonden, blijven ze echter niet standaard behouden nadat de OAuth-aanmelding is voltooid en wordt teruggeleid naar uw app. Gebruikers krijgen vervolgens een suboptimale ervaring wanneer ze opnieuw naar het gewenste anker moeten navigeren. Deze beperking geldt voor alle verificatieoplossingen aan de serverzijde.

In App Service-verificatie kunt u URL-fragmenten behouden in de OAuth-aanmelding. Hiervoor stelt u een app-instelling in die wordt aangeroepen WEBSITE_AUTH_PRESERVE_URL_FRAGMENTtrue. U kunt dit doen in Azure Portal of gewoon de volgende opdracht uitvoeren in Azure Cloud Shell:

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

Het domein van aanmeldingsaccounts beperken

Met zowel Microsoft-account als Microsoft Entra-id kunt u zich aanmelden vanuit meerdere domeinen. Microsoft-account staat bijvoorbeeld outlook.com- live.com- en hotmail.com-accounts toe. Microsoft Entra ID staat een willekeurig aantal aangepaste domeinen toe voor de aanmeldingsaccounts. Het is echter mogelijk dat u uw gebruikers rechtstreeks naar uw eigen merk Microsoft Entra-aanmeldingspagina (zoals contoso.com) wilt versnellen. Volg deze stappen om de domeinnaam van de aanmeldingsaccounts voor te stellen.

  1. https://resources.azure.comSelecteer Lezen/schrijven boven aan de pagina.

  2. Navigeer in de linkerbrowser naar abonnementsnaam>><resourceGroups<>resource-group-providers>>>Microsoft.Web>sites><app-name>>config authsettingsV2.>

  3. Klik op Bewerken.

  4. Voeg een loginParameters matrix toe met een domain_hint item.

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

  5. Klik op Put.

Met deze instelling wordt de domain_hint querytekenreeksparameter toegevoegd aan de omleidings-URL voor aanmelding.

Belangrijk

Het is mogelijk dat de client de domain_hint parameter verwijdert na ontvangst van de omleidings-URL en zich vervolgens aanmeldt met een ander domein. Dus hoewel deze functie handig is, is het geen beveiligingsfunctie.

Gebruikers autoriseren of weigeren

Hoewel App Service zorgt voor de eenvoudigste autorisatiecase (dat wil zeggen niet-geverifieerde aanvragen weigeren), is het mogelijk dat uw app nauwkeuriger autorisatiegedrag vereist, zoals het beperken van de toegang tot slechts een specifieke groep gebruikers. In bepaalde gevallen moet u aangepaste toepassingscode schrijven om toegang tot de aangemelde gebruiker toe te staan of te weigeren. In andere gevallen kunnen App Service of uw id-provider helpen zonder dat er codewijzigingen nodig zijn.

Serverniveau (alleen Windows-apps)

Voor elke Windows-app kunt u autorisatiegedrag van de IIS-webserver definiëren door het Web.config-bestand te bewerken. Linux-apps maken geen gebruik van IIS en kunnen niet worden geconfigureerd via Web.config.

  1. Ga naar https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. Navigeer in de browserverkenner van uw App Service-bestanden naar site/wwwroot. Als er geen Web.config bestaat, maakt u deze door Nieuw bestand te +>selecteren.

  3. Selecteer het potlood voor Web.config om het te bewerken. Voeg de volgende configuratiecode toe en klik op Opslaan. Als Web.config al bestaat, voegt u het <authorization> element toe met alles erin. Voeg de accounts toe die u wilt toestaan in het <allow> element.

    <?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>

Niveau van id-provider

De id-provider kan bepaalde turn-key-autorisatie bieden. Voorbeeld:

Toepassingsniveau

Als een van de andere niveaus niet de autorisatie biedt die u nodig hebt of als uw platform of id-provider niet wordt ondersteund, moet u aangepaste code schrijven om gebruikers te autoriseren op basis van de gebruikersclaims.

Meer resources