Delen via

Pas de aanmeldingen en afmeldingen aan in Azure App Service-authenticatie

  • Artikel

Deze artikel laat zien hoe je aanmeldingen en afmeldingen van gebruikers kunt aanpassen terwijl je gebruikmaakt van de ingebouwde authenticatie en autorisatie in Azure App Service.

Gebruik meerdere aanmeldproviders

De configuratie van Azure Portal biedt geen kant-en-klare manier om meerdere aanmeldingsproviders aan uw gebruikers te presenteren. U wilt bijvoorbeeld zowel Facebook als X als opties aanbieden. Meerdere aanmeldingsproviders toevoegen aan uw app:

  1. In de Azure-portal, in uw web-app, selecteer Instellingen>Authenticatie.

  2. Selecteer Bewerken voor verificatie-instellingen.

  3. Voor Toegang beperken selecteert u Niet-geverifieerde toegang toestaan.

  4. Voeg op de aanmeldingspagina, de navigatiebalk of een andere locatie in uw app een aanmeldingskoppeling toe aan elk van de providers die u hebt ingeschakeld (/.auth/login/<provider>). For example:

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

Wanneer de gebruiker een van de links selecteert, opent de betreffende pagina voor aanmelding.

Om de gebruiker na het aanmelden naar een aangepaste URL te leiden, gebruikt u de post_login_redirect_uri query string parameter. Als u de gebruiker bijvoorbeeld wilt verplaatsen naar /Home/Index na aanmelding, gebruikt u de volgende HTML-code:

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

Opmerking

Verwar deze waarde niet met de omleidings-URI in de configuratie van uw id-provider.

Gebruik klantgerichte aanmelding

Bij een clientgestuurde aanmelding meldt de applicatie de gebruiker aan bij de identiteitsprovider met behulp van een providerspecifieke SDK. De toepassingscode verzendt vervolgens het resulterende verificatietoken naar App Service voor validatie met behulp van een HTTP-aanvraag POST . Met deze validatie zelf hebben gebruikers geen toegang tot de gewenste app-resources. Een geslaagde validatie geeft gebruikers een sessietoken dat ze kunnen gebruiken voor toegang tot app-resources. Zie Verificatiestroom voor meer informatie.

Om de provider-token te valideren, moet de App Service-app eerst worden geconfigureerd met de gewenste provider. Tijdens runtime, nadat je het authenticatietoken van je provider hebt verkregen, stuur je het token naar /.auth/login/<provider> voor validatie. For example:

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

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

Het tokenformaat varieert enigszins afhankelijk van de aanbieder:

Waarde van de aanbieder Required in request body Opmerkingen
aad {"access_token":"<access_token>"} De eigenschappen id_token, refresh_token en expires_in zijn optioneel.
google {"id_token":"<id_token>"} De authorization_code eigenschap is optioneel. Het opgeven van een authorization_code waarde voegt een access token en een refresh token toe aan de tokenstore. When you specify authorization_code, you can optionally accompany it with a redirect_uri property.
facebook {"access_token":"<user_access_token>"} Gebruik een geldig user access token van Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<access_token_secret>"}

Note

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

If the provider token is validated successfully, the API returns with an authenticationToken value in the response body. This value is your session token. Zie Werken met gebruikersidentiteiten in Azure App Service-verificatie voor meer informatie over gebruikersclaims.

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

Nadat u dit sessie-token hebt, kunt u toegang krijgen tot beschermde app-bronnen door de X-ZUMO-AUTH header toe te voegen aan uw HTTP-verzoeken. For example:

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

Sign out of a session

Gebruikers kunnen een afmelding starten door een GET verzoek te sturen naar het /.auth/logout eindpunt van de app. Het GET verzoek:

  • Verwijdert authenticatiecookies uit de huidige sessie.
  • Verwijdert de token(s) van de huidige gebruiker uit de tokenopslag.
  • Voert een afmelding aan de serverzijde uit bij de id-provider voor Microsoft Entra en Google.

Hier is een eenvoudige afmeldingslink op een webpagina:

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

Standaard leidt een succesvolle afmelding de cliënt om naar de URL /.auth/logout/complete. You can change the post-sign-out redirect page by adding the post_logout_redirect_uri query parameter. For example:

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

We recommend that you encode the value of 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. The following example redirects to an https://myexternalurl.com URL that's not hosted in the same domain:

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

Run the following command in Azure Cloud Shell:

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

Preserve URL fragments

After users sign in to your app, they usually want to be redirected to the same section of the same page, such as /wiki/Main_Page#SectionZ. nl-NL: Echter, omdat URL-fragmenten (bijvoorbeeld, #SectionZ) nooit naar de server worden verzonden, blijven ze standaard niet behouden nadat het OAuth-aanmeldproces is voltooid en terug naar uw app wordt omgeleid. Gebruikers krijgen dan een minder dan optimale ervaring wanneer ze opnieuw naar de gewenste anker moeten gaan. Deze beperking geldt voor alle server-side authenticatieoplossingen.

In App Service-verificatie kunt u URL-fragmenten behouden tijdens het OAuth-aanmeldproces door WEBSITE_AUTH_PRESERVE_URL_FRAGMENT in te stellen op true. U gebruikt deze app-instelling in de Azure-portal of u kunt de volgende opdracht uitvoeren in Cloud Shell:

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

Stel de domeinaanwijzing in voor aanmeldaccounts

Zowel Microsoft-accounts als Microsoft Entra stellen gebruikers in staat om zich vanuit meerdere domeinen aan te melden. Een Microsoft-account staat bijvoorbeeld outlook.com, live.com en hotmail.com accounts toe. Microsoft Entra staat een onbeperkt aantal aangepaste domeinen toe voor de aanmeldaccounts. Echter, u wilt uw gebruikers wellicht direct naar uw eigen, merkgebonden Microsoft Entra-aanmeldingspagina versnellen (zoals contoso.com).

Om de domeinnaam van de aanmeldaccounts voor te stellen, volgt u deze stappen:

  1. In Resource Explorer, at the top of the page, select Read/Write.

  2. On the left pane, go to subscriptions>subscription-name>resourceGroups>resource-group-name>providers>Microsoft.Web>sites>app-name>config>authsettingsV2.

  3. Kies Bewerken.

  4. Add a loginParameters array with a domain_hint item:

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

  5. Select Put.

This setting appends the domain_hint query string parameter to the sign-in redirect URL.

Important

It's possible for the client to remove the domain_hint parameter after receiving the redirect URL, and then sign in with a different domain. So although this function is convenient, it's not a security feature.

Authorize or deny users

App Service zorgt voor de eenvoudigste autorisatiecase, bijvoorbeeld het weigeren van niet-geverifieerde aanvragen. Uw app vereist mogelijk meer fijnmazig autorisatiegedrag, zoals het beperken van de toegang tot alleen een specifieke groep gebruikers.

Mogelijk moet u aangepaste toepassingscode schrijven om toegang tot de aangemelde gebruiker toe te staan of te weigeren. In sommige gevallen kunnen App Service of uw id-provider helpen zonder dat er codewijzigingen nodig zijn.

Server level (Windows apps only)

For any Windows app, you can define authorization behavior of the IIS web server by editing the web.config file. Linux-apps gebruiken geen IIS en kunnen niet worden geconfigureerd via web.config.

  1. Als u naar de Kudu-console voor foutopsporing voor uw app wilt gaan, selecteert uGeavanceerde hulpprogramma's voor ontwikkelingsprogramma's> en selecteert u Go. Selecteer vervolgens Debug-console.

    U kunt deze pagina ook openen met deze URL: https://<app-name>-<random-hash>.scm.<region>.azurewebsites.net/DebugConsole. Als u de willekeurige hash- en regiowaarden wilt ophalen, kopieert u het standaarddomein in uw app-overzicht.

  2. In de browserverkenner van uw App Service-bestanden, ga naar site/wwwroot. Als web.config niet bestaat, maak het dan aan door te selecteren +>Nieuw bestand.

  3. Select the pencil for web.config to edit the file. Add the following configuration code, and then select Save. If web.config already exists, just add the <authorization> element with everything in it. Voeg in het <allow> element de accounts toe die je wilt toestaan.

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

Identity provider level

The identity provider might provide certain turnkey authorization. For example:

Applicatieniveau

If either of the other levels doesn't provide the authorization that you need, or if your platform or identity provider isn't supported, you must write custom code to authorize users based on the user claims.

Verwante inhoud