Delen via

Verificatie en autorisatie in Azure-app Service en Azure Functions

  • Artikel

Notitie

Vanaf 1 juni 2024 hebben alle nieuw gemaakte App Service-apps de mogelijkheid om een unieke standaardhostnaam te genereren met behulp van de naamconventie <app-name>-<random-hash>.<region>.azurewebsites.net. Bestaande app-namen blijven ongewijzigd.

Voorbeeld: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Raadpleeg de unieke standaardhostnaam voor App Service-resource voor meer informatie.

Azure-app Service biedt ingebouwde verificatie- en autorisatiemogelijkheden (ook wel 'Eenvoudige verificatie' genoemd), zodat u gebruikers kunt aanmelden en gegevens kunt openen door minimale of geen code te schrijven in uw web-app, RESTful-API en mobiele back-end, en ook Azure Functions. In dit artikel wordt beschreven hoe App Service helpt verificatie en autorisatie voor uw app te vereenvoudigen.

Waarom de ingebouwde verificatie gebruiken?

U hoeft deze functie niet te gebruiken voor verificatie en autorisatie. U kunt de gebundelde beveiligingsfuncties in uw webframework naar keuze gebruiken of u kunt uw eigen hulpprogramma's schrijven. U moet er echter voor zorgen dat uw oplossing up-to-date blijft met de nieuwste beveiligings-, protocol- en browserupdates.

Het implementeren van een veilige oplossing voor verificatie (aanmeldingsgebruikers) en autorisatie (het verlenen van toegang tot beveiligde gegevens) kan veel moeite kosten. U moet ervoor zorgen dat u de aanbevolen procedures en standaarden voor de branche volgt en uw implementatie up-to-date houdt. Met de ingebouwde verificatiefunctie voor App Service en Azure Functions kunt u tijd en moeite besparen door kant-en-klare verificatie te bieden met federatieve id-providers, zodat u zich kunt richten op de rest van uw toepassing.

  • Azure-app Service kunt u diverse verificatiemogelijkheden integreren in uw web-app of API zonder ze zelf te implementeren.
  • Het is rechtstreeks ingebouwd in het platform en vereist geen specifieke taal, SDK, beveiligingsexpertise of zelfs code die moet worden gebruikt.
  • U kunt integreren met meerdere aanmeldingsproviders. Bijvoorbeeld Microsoft Entra, Facebook, Google, X.

Uw app moet mogelijk complexere scenario's ondersteunen, zoals Visual Studio-integratie of incrementele toestemming. Er zijn verschillende verificatieoplossingen beschikbaar ter ondersteuning van deze scenario's. Lees identiteitsscenario's voor meer informatie.

Id-providers

App Service maakt gebruik van federatieve identiteit, waarbij een externe id-provider de gebruikersidentiteiten en verificatiestroom voor u beheert. De volgende id-providers zijn standaard beschikbaar:

Provider Aanmeldingseindpunt Instructies
Microsoft Entra /.auth/login/aad Aanmelding voor App Service Microsoft Entra-platform
Facebook /.auth/login/facebook Aanmelding bij App Service Facebook
Google /.auth/login/google Google-aanmelding voor App Service
X /.auth/login/x App Service X-aanmelding
GitHub /.auth/login/github Aanmelding bij App Service GitHub
Aanmelden met Apple /.auth/login/apple Aanmelden bij App Service met Apple-aanmelding (preview)
Elke OpenID Connect-provider /.auth/login/<providerName> Aanmelding bij App Service OpenID Connect

Wanneer u deze functie configureert met een van deze providers, is het aanmeldingseindpunt beschikbaar voor gebruikersverificatie en voor validatie van verificatietokens van de provider. U kunt uw gebruikers een willekeurig aantal van deze aanmeldingsopties bieden.

Overwegingen voor het gebruik van ingebouwde verificatie

Als u deze functie inschakelt, worden alle aanvragen voor uw toepassing automatisch omgeleid naar HTTPS, ongeacht de App Service-configuratie-instelling om HTTPS af te dwingen. U kunt dit uitschakelen met de requireHttps instelling in de V2-configuratie. We raden u echter aan om te blijven hangen met HTTPS en u moet ervoor zorgen dat er nooit beveiligingstokens worden verzonden via niet-beveiligde HTTP-verbindingen.

App Service kan worden gebruikt voor verificatie met of zonder de toegang tot uw site-inhoud en API's te beperken. Toegangsbeperkingen kunnen worden ingesteld in de sectie Verificatieverificatie-instellingen> van uw web-app. Als u de toegang tot apps alleen wilt beperken tot geverifieerde gebruikers, stelt u actie in die moet worden uitgevoerd wanneer de aanvraag niet wordt geverifieerd om u aan te melden met een van de geconfigureerde id-providers. Als u de toegang wilt verifiëren maar niet wilt beperken, stelt u actie in die moet worden uitgevoerd wanneer de aanvraag niet is geverifieerd bij 'Anonieme aanvragen toestaan (geen actie).'

Belangrijk

U moet elke app-registratie een eigen machtiging en toestemming geven. Vermijd het delen van machtigingen tussen omgevingen met behulp van afzonderlijke app-registraties voor afzonderlijke implementatiesites. Bij het testen van nieuwe code kan deze procedure helpen voorkomen dat problemen van invloed zijn op de productie-app.

Hoe het werkt

Functiearchitectuur

Verificatiestroom

Autorisatiegedrag

Tokenarchief

Logboekregistratie en tracering

Functiearchitectuur

Het onderdeel verificatie- en autorisatie-middleware is een functie van het platform dat wordt uitgevoerd op dezelfde VM als uw toepassing. Wanneer deze is ingeschakeld, wordt elke binnenkomende HTTP-aanvraag doorgegeven voordat deze wordt verwerkt door uw toepassing.

Een architectuurdiagram met aanvragen die worden onderschept door een proces in de site-sandbox die communiceert met id-providers voordat verkeer naar de geïmplementeerde site wordt toegestaan

De platform-middleware verwerkt verschillende dingen voor uw app:

  • Verifieert gebruikers en clients met de opgegeven id-provider(s)
  • Hiermee worden OAuth-tokens gevalideerd, opgeslagen en vernieuwd die zijn uitgegeven door de geconfigureerde id-provider(s)
  • Beheert de geverifieerde sessie
  • Injecteert identiteitsgegevens in HTTP-aanvraagheaders

De module wordt afzonderlijk van uw toepassingscode uitgevoerd en kan worden geconfigureerd met behulp van Azure Resource Manager-instellingen of met behulp van een configuratiebestand. Er zijn geen SDK's, specifieke programmeertalen of wijzigingen in uw toepassingscode vereist.

Functiearchitectuur in Windows (niet-containerimplementatie)

De verificatie- en autorisatiemodule wordt uitgevoerd als een systeemeigen IIS-module in dezelfde sandbox als uw toepassing. Wanneer deze is ingeschakeld, wordt elke binnenkomende HTTP-aanvraag doorgegeven voordat deze wordt verwerkt door uw toepassing.

Functiearchitectuur in Linux en containers

De verificatie- en autorisatiemodule wordt uitgevoerd in een afzonderlijke container, geïsoleerd van uw toepassingscode. Met behulp van wat bekend staat als het Ambassador-patroon, communiceert het met het binnenkomende verkeer om vergelijkbare functionaliteit uit te voeren als in Windows. Omdat het niet in het proces wordt uitgevoerd, is er geen directe integratie met specifieke taalframeworks mogelijk; De relevante informatie die uw app nodig heeft, wordt echter doorgegeven met behulp van aanvraagheaders, zoals hieronder wordt uitgelegd.

Verificatiestroom

De verificatiestroom is voor alle providers hetzelfde, maar is afhankelijk van of u zich wilt aanmelden met de SDK van de provider:

  • Zonder provider-SDK: de toepassing delegeert federatieve aanmelding bij App Service. Dit is meestal het geval bij browser-apps, die de aanmeldingspagina van de provider aan de gebruiker kunnen presenteren. De servercode beheert het aanmeldingsproces, dus het wordt ook wel servergestuurde stroom of serverstroom genoemd. Dit geval is van toepassing op browser-apps en mobiele apps die gebruikmaken van een ingesloten browser voor verificatie.
  • Met provider-SDK: De toepassing meldt gebruikers handmatig aan bij de provider en verzendt vervolgens het verificatietoken naar App Service voor validatie. Dit is meestal het geval bij apps zonder browser, die de aanmeldingspagina van de provider niet aan de gebruiker kunnen presenteren. De toepassingscode beheert het aanmeldingsproces, dus dit wordt ook wel clientgestuurde stroom of clientstroom genoemd. Dit geval is van toepassing op REST API's, Azure Functions- en JavaScript-browserclients, evenals browser-apps die meer flexibiliteit nodig hebben in het aanmeldingsproces. Het is ook van toepassing op systeemeigen mobiele apps die gebruikers aanmelden met behulp van de SDK van de provider.

Aanroepen van een vertrouwde browser-app in App Service naar een andere REST API in App Service of Azure Functions kunnen worden geverifieerd met behulp van de servergestuurde stroom. Zie Aanmeldingen en afmeldingen aanpassen voor meer informatie.

In de onderstaande tabel ziet u de stappen van de verificatiestroom.

Stap Zonder provider-SDK Met provider-SDK
1. Gebruiker aanmelden Stuurt de client om naar /.auth/login/<provider>. Clientcode meldt de gebruiker rechtstreeks aan met de SDK van de provider en ontvangt een verificatietoken. Zie de documentatie van de provider voor meer informatie.
2. Na verificatie Provider stuurt de client om naar /.auth/login/<provider>/callback. Clientcode plaatst token van provider naar /.auth/login/<provider> voor validatie.
3. Een geverifieerde sessie tot stand brengen App Service voegt geverifieerde cookie toe aan het antwoord. App Service retourneert een eigen verificatietoken naar clientcode.
4. Geverifieerde inhoud leveren Client bevat verificatiecookies in volgende aanvragen (automatisch verwerkt door de browser). Clientcode presenteert verificatietoken in X-ZUMO-AUTH de header.

Voor clientbrowsers kan App Service automatisch alle niet-geverifieerde gebruikers doorsturen naar /.auth/login/<provider>. U kunt gebruikers ook presenteren met een of meer /.auth/login/<provider> koppelingen om u aan te melden bij uw app met behulp van hun provider van keuze.

Autorisatiegedrag

Belangrijk

Deze functie biedt standaard alleen verificatie, niet autorisatie. Uw toepassing moet mogelijk nog steeds autorisatiebeslissingen nemen, naast eventuele controles die u hier configureert.

In Azure Portal kunt u App Service configureren met een aantal gedragingen wanneer binnenkomende aanvragen niet worden geverifieerd. In de volgende koppen worden de opties beschreven.

Toegang beperken

  • Niet-geverifieerde aanvragen toestaan Met deze optie wordt de autorisatie van niet-geverifieerd verkeer naar uw toepassingscode uitgesteld. Voor geverifieerde aanvragen geeft App Service ook verificatiegegevens door in de HTTP-headers.

    Deze optie biedt meer flexibiliteit bij het verwerken van anonieme aanvragen. Hiermee kunt u bijvoorbeeld meerdere aanmeldingsproviders aan uw gebruikers presenteren. U moet echter code schrijven.

  • Verificatie vereisen Deze optie weigert niet-geverifieerd verkeer naar uw toepassing. Specifieke actie die moet worden ondernomen, wordt opgegeven in de sectie Niet-geverifieerde aanvragen .

    Met deze optie hoeft u geen verificatiecode in uw app te schrijven. Fijner autorisatie, zoals rolspecifieke autorisatie, kan worden verwerkt door de claims van de gebruiker te controleren (zie Gebruikersclaims van Access).

    Let op

    Het beperken van de toegang op deze manier is van toepassing op alle aanroepen naar uw app, wat mogelijk niet wenselijk is voor apps die een openbaar beschikbare startpagina willen, zoals in veel toepassingen met één pagina.

    Notitie

    Wanneer u de Microsoft-id-provider gebruikt voor gebruikers in uw organisatie, is het standaardgedrag dat elke gebruiker in uw Microsoft Entra-tenant een token voor uw toepassing kan aanvragen. U kunt de toepassing in Microsoft Entra configureren als u de toegang tot uw app wilt beperken tot een gedefinieerde set gebruikers. App Service biedt ook enkele eenvoudige ingebouwde autorisatiecontroles die kunnen helpen bij sommige validaties. Zie de basisprincipes van Microsoft Entra-autorisatie voor meer informatie over autorisatie in Microsoft Entra.

Niet-geverifieerde aanvragen

  • HTTP 302 Gevonden omleiding: aanbevolen voor websites omleidingsactie naar een van de geconfigureerde id-providers. In deze gevallen wordt een browserclient omgeleid naar /.auth/login/<provider> de provider die u kiest.
  • HTTP 401 Niet geautoriseerd: aanbevolen voor API's als de anonieme aanvraag afkomstig is van een systeemeigen mobiele app, is het geretourneerde antwoord een HTTP 401 Unauthorized. U kunt de afwijzing ook zo configureren dat deze voor alle aanvragen geldt HTTP 401 Unauthorized .
  • HTTP 403 Verboden configureert de afwijzing als een HTTP 403 Forbidden voor alle aanvragen.
  • HTTP 404 Niet gevonden Configureert de afwijzing als een HTTP 404 Not found voor alle aanvragen.

Tokenarchief

App Service biedt een ingebouwd tokenarchief, een opslagplaats met tokens die zijn gekoppeld aan de gebruikers van uw web-apps, API's of systeemeigen mobiele apps. Wanneer u verificatie inschakelt bij een provider, is dit tokenarchief direct beschikbaar voor uw app. Als uw toepassingscode namens de gebruiker toegang nodig heeft tot gegevens van deze providers, zoals:

  • posten op de Facebook-tijdlijn van de geverifieerde gebruiker
  • de bedrijfsgegevens van de gebruiker lezen met behulp van de Microsoft Graph API

Normaal gesproken moet u code schrijven om deze tokens in uw toepassing te verzamelen, op te slaan en te vernieuwen. Met het tokenarchief haalt u alleen de tokens op wanneer u ze nodig hebt en geeft u App Service de opdracht om ze te vernieuwen wanneer ze ongeldig worden.

De id-tokens, toegangstokens en vernieuwingstokens worden in de cache opgeslagen voor de geverifieerde sessie en ze zijn alleen toegankelijk voor de bijbehorende gebruiker.

Als u niet met tokens in uw app hoeft te werken, kunt u het tokenarchief uitschakelen op de pagina Verificatie/autorisatie van uw app.

Logboekregistratie en tracering

Als u logboekregistratie van toepassingen inschakelt, ziet u verificatie- en autorisatietraceringen rechtstreeks in uw logboekbestanden. Als u een verificatiefout ziet die u niet had verwacht, kunt u gemakkelijk alle details vinden door in uw bestaande toepassingslogboeken te zoeken. Als u tracering van mislukte aanvragen inschakelt, kunt u precies zien welke rol de verificatie- en autorisatiemodule kan hebben gespeeld in een mislukte aanvraag. Zoek in de traceerlogboeken naar verwijzingen naar een module met de naam EasyAuthModule_32/64.

Beperking van vervalsing van aanvragen op meerdere sites

App Service-verificatie beperkt CSRF door clientaanvragen te controleren op de volgende voorwaarden:

  • Het is een POST-aanvraag die is geverifieerd met behulp van een sessiecooky.
  • De aanvraag is afkomstig van een bekende browser (zoals bepaald door de HTTP-header User-Agent ).
  • De HTTP- Origin of HTTP-header Referer ontbreekt of bevindt zich niet in de geconfigureerde lijst met goedgekeurde externe domeinen voor omleiding.
  • De HTTP-header ontbreekt of bevindt zich niet in de geconfigureerde lijst met CORS-oorsprongen Origin .

Wanneer een aanvraag aan al deze voorwaarden voldoet, weigert App Service-verificatie deze automatisch. U kunt deze beperkingslogica tijdelijk oplossen door uw externe domein toe te voegen aan de omleidingslijst voor verificatie>bewerken van verificatie-instellingen>Toegestane externe omleidings-URL's.

Overwegingen bij het gebruik van Azure Front Door

Wanneer u Azure-app Service gebruikt met verificatie achter Azure Front Door of andere omgekeerde proxy's, moet rekening worden gehouden met een aantal extra zaken.

  • Caching uitschakelen voor de verificatiewerkstroom.

    Zie Cache uitschakelen voor verificatiewerkstroom voor meer informatie over het configureren van regels in Azure Front Door om caching uit te schakelen voor verificatie- en autorisatiegerelateerde pagina's.

  • Gebruik het Front Door-eindpunt voor omleidingen.

    App Service is meestal niet rechtstreeks toegankelijk wanneer ze worden weergegeven via Azure Front Door. Dit kan bijvoorbeeld worden voorkomen door App Service beschikbaar te maken via Private Link in Azure Front Door Premium. Om te voorkomen dat de verificatiewerkstroom verkeer rechtstreeks naar App Service omleidt, is het belangrijk dat u de toepassing configureert om terug te leiden naar https://<front-door-endpoint>/.auth/login/<provider>/callback.

  • Zorg ervoor dat App Service de juiste omleidings-URI gebruikt

    In sommige configuraties gebruikt de App Service de App Service-FQDN als de omleidings-URI in plaats van de Front Door-FQDN. Dit leidt tot een probleem wanneer de client wordt omgeleid naar App Service in plaats van Front Door. Als u dit wilt wijzigen, moet de forwardProxy instelling zodanig worden ingesteld Standard dat App Service de X-Forwarded-Host header respecteert die door Azure Front Door is ingesteld.

    Andere omgekeerde proxy's, zoals Azure-toepassing Gateway of producten van derden, kunnen verschillende headers gebruiken en een andere forwardProxy-instelling nodig hebben.

    Deze configuratie kan momenteel niet worden uitgevoerd via Azure Portal en moet worden uitgevoerd via az rest:

    Exportinstellingen

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

    Instellingen bijwerken

    Zoeken naar

    "httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

    en zorg ervoor dat deze is ingesteld om de X-Forwarded-Host header te Standard respecteren die convention wordt gebruikt door Azure Front Door.

    Importinstellingen

    az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Meer resources

Voorbeelden: