Delen via

Verificatie en autorisatie in Azure-app Service en Azure Functions

Azure App Service biedt ingebouwde verificatie (aanmeldingsgebruikers) en autorisatiemogelijkheden (die toegang bieden tot beveiligde gegevens). Deze mogelijkheden worden soms Easy Auth genoemd. U kunt ze gebruiken om gebruikers aan te melden en toegang te krijgen tot gegevens door weinig of geen code te schrijven in uw web-app, RESTful-API, mobiele server en functies.

In dit artikel wordt beschreven hoe App Service helpt verificatie en autorisatie voor uw app te vereenvoudigen.

Redenen om ingebouwde verificatie te gebruiken

Als u verificatie en autorisatie wilt implementeren, kunt u de gebundelde beveiligingsfuncties in uw webframework van keuze gebruiken of uw eigen hulpprogramma's schrijven. Het implementeren van een veilige oplossing voor verificatie en autorisatie kan aanzienlijke inspanningen vergen. U moet best practices en standaarden voor de branche volgen. U moet er ook voor zorgen dat uw oplossing up-to-date blijft met de nieuwste beveiligings-, protocol- en browserupdates.

Met de ingebouwde mogelijkheden van App Service en Azure Functions kunt u tijd en moeite besparen door kant-en-klare verificatie met federatieve id-providers te bieden, zodat u zich kunt richten op de rest van uw toepassing.

Met App Service kunt u verificatiemogelijkheden integreren in uw web-app of API zonder ze zelf te implementeren. Deze functie is rechtstreeks ingebouwd in het platform en vereist geen specifieke taal, SDK, beveiligingsexpertise of code. U kunt het integreren met meerdere aanmeldingsproviders, zoals Microsoft Entra, Facebook, Google en 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. Zie verificatiescenario's en aanbevelingen voor meer informatie.

Identiteitsproviders

App Service maakt gebruik van federatieve identiteit. Een Microsoft- of niet-Microsoft-id-provider beheert de gebruikersidentiteiten en verificatiestroom voor u. De volgende id-providers zijn standaard beschikbaar:

Aanbieder Aanmeldingseindpunt Stapsgewijze handleiding
Microsoft Entra /.auth/login/aad Aanmelden bij het App Service Microsoft Entra-platform
Facebook /.auth/login/facebook Aanmelden bij App Service Facebook
Google /.auth/login/google Google-aanmelding bij App Service
X /.auth/login/x Aanmelden bij App Service X
GitHub /.auth/login/github Aanmelding bij App Service GitHub
Apple- /.auth/login/apple Aanmelden bij App Service via Apple-aanmelding (preview)
Elke OpenID Connect-provider /.auth/login/<providerName> Aanmelden 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 ingebouwde verificatie inschakelt, worden alle aanvragen voor uw toepassing automatisch omgeleid naar HTTPS, ongeacht de App Service-configuratie-instelling om HTTPS af te dwingen. U kunt deze automatische omleiding uitschakelen met behulp van de requireHttps instelling in de V2-configuratie. We raden u echter aan HTTPS te blijven gebruiken en ervoor te zorgen dat er nooit beveiligingstokens worden verzonden via niet-beveiligde HTTP-verbindingen.

U kunt App Service gebruiken voor verificatie met of zonder de toegang tot uw site-inhoud en API's te beperken. Stel toegangsbeperkingen in de Instellingen>Verificatie>Verificatie-instellingen sectie van uw web-app in:

  • Als u de toegang tot apps wilt beperken tot alleen 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 wordt geverifieerd voor 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. Wanneer u nieuwe code test, kan deze procedure helpen voorkomen dat problemen van invloed zijn op de productie-app.

Hoe het werkt

Kenmerkarchitectuur

Het middlewareonderdeel verificatie en autorisatie is een functie van het platform dat wordt uitgevoerd op dezelfde virtuele machine als uw toepassing. Wanneer u deze inschakelt, passeert elke binnenkomende HTTP-aanvraag dat onderdeel voordat de toepassing het verwerkt.

Architectuurdiagram met 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-providers
  • OAuth-tokens valideren, opslaan en vernieuwen die zijn uitgegeven door de geconfigureerde id-providers
  • Beheert de geverifieerde sessie
  • Injecteert identiteitsgegevens in HTTP-aanvraagheaders

De module wordt afzonderlijk van uw toepassingscode uitgevoerd. U kunt deze configureren 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 u deze inschakelt, wordt elke binnenkomende HTTP-aanvraag doorgegeven voordat uw toepassing deze verwerkt.

Functiearchitectuur in Linux en containers

De verificatie- en autorisatiemodule wordt uitgevoerd in een afzonderlijke container die is geïsoleerd van uw toepassingscode. De module maakt gebruik van het Ambassador-patroon om te communiceren met het binnenkomende verkeer om vergelijkbare functionaliteit uit te voeren als in Windows. Omdat deze niet in proces wordt uitgevoerd, is er geen directe integratie met specifieke taalframeworks mogelijk. De relevante informatie die uw app nodig heeft, wordt echter doorgegeven in aanvraagheaders.

Authenticatiestroom

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

  • Zonder provider-SDK: de toepassing delegeert federatieve aanmelding bij App Service. Deze delegatie is doorgaans het geval bij browser-apps, die de aanmeldingspagina van de provider aan de gebruiker kunnen presenteren. De servercode beheert het aanmeldingsproces, dus dit 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. Vervolgens wordt het verificatietoken naar App Service verzonden voor validatie. Dit proces is meestal het geval bij browserloze apps, 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, naast 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 via de servergestuurde stroom. Voor meer informatie, zie Aanmelden en afmelden aanpassen in de Azure App Service-verificatie.

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

Stap Zonder provider-SDK Met provider-SDK
1. Meld u aan bij de gebruiker Provider leidt 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. Post-authenticatie uitvoeren Provider leidt de client om naar /.auth/login/<provider>/callback. Clientcode plaatst het token van de provider naar /.auth/login/<provider> voor validatie.
3. Een geverifieerde sessie tot stand brengen App Service voegt een geverifieerde cookie toe aan het antwoord. App Service retourneert een eigen verificatietoken naar de clientcode.
4. Geverifieerde inhoud leveren Client bevat een authenticatiecookie in de daaropvolgende aanvragen (automatisch door de browser afgehandeld). Clientcode presenteert het verificatietoken in de X-ZUMO-AUTH header.

Voor clientbrowsers kan App Service automatisch alle niet-geverifieerde gebruikers doorsturen naar /.auth/login/<provider>. U kunt gebruikers ook de mogelijkheid aanbieden om zich aan te melden bij uw app via een of meer /.auth/login/<provider> koppelingen, door gebruik te maken van hun gewenste provider.

Autorisatiegedrag

In Azure Portal kunt u App Service configureren met verschillende gedragingen wanneer een binnenkomende aanvraag niet wordt geverifieerd. In de volgende secties worden de opties beschreven.

Belangrijk

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

Beperkte toegang

  • 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: met deze optie wordt niet-geverifieerd verkeer naar uw toepassing geweigerd. Specifieke actie die moet worden ondernomen, wordt opgegeven in de sectie Niet-geverifieerde aanvragen verderop in dit artikel.

    Met deze optie hoeft u geen verificatiecode in uw app te schrijven. U kunt fijnere autorisatie, zoals rolspecifieke autorisatie, afhandelen door de claims van de gebruiker te inspecteren.

    Waarschuwing

    Het op deze manier beperken van toegang geldt voor alle oproepen naar je app, wat mogelijk niet wenselijk is voor apps die een openbaar toegankelijke startpagina willen, zoals bij veel single-page applicaties. Als uitzonderingen nodig zijn, moet je uitgesloten paden configureren in een configuratiebestand.

    Notitie

    Bij het gebruik van de Microsoft identiteitsprovider 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 enkele validaties. Zie de basisprincipes van Microsoft Entra-autorisatie voor meer informatie over autorisatie in Microsoft Entra.

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 Found redirect: aanbevolen voor websites: Verwijst de actie door naar een van de geconfigureerde identiteitsproviders. In deze gevallen wordt een browserclient omgeleid naar /.auth/login/<provider> de provider die u kiest.
  • HTTP 401 Niet geautoriseerd: aanbevolen voor API's: retourneert een HTTP 401 Unauthorized antwoord als de anonieme aanvraag afkomstig is van een systeemeigen mobiele app. U kunt de afwijzing ook zo configureren dat deze voor alle aanvragen geldt HTTP 401 Unauthorized .
  • HTTP 403 Verboden: configureert de afwijzing als HTTP 403 Forbidden voor alle aanvragen.
  • HTTP 404 Niet gevonden: hiermee configureert u de afwijzing voor HTTP 404 Not found alle aanvragen.

Tokenwinkel

App Service biedt een ingebouwd tokenarchief. Een tokenarchief is 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 moet hebben tot gegevens van deze providers, moet u doorgaans code schrijven om deze tokens in uw toepassing te verzamelen, op te slaan en te vernieuwen. Acties kunnen zijn:

  • Plaats een bericht op de Facebook-tijdlijn van de geverifieerde gebruiker.
  • Lees de bedrijfsgegevens van de gebruiker met behulp van de Microsoft Graph API.

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. Alleen de gekoppelde gebruiker heeft toegang tot hen.

Als u niet met tokens in uw app hoeft te werken, kunt u de tokenopslag uitschakelen op de Instellingen>Authenticatiepagina van uw app.

Logboekregistratie en tracering

Als u toepassingslogboekregistratie inschakelt, worden verificatie- en autorisatietraceringen rechtstreeks in uw logboekbestanden weergegeven. 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 spelen in een mislukte aanvraag. Zoek in de traceerlogboeken naar verwijzingen naar een module met de naam EasyAuthModule_32/64.

Beperking van aanvraagvervalsing op meerdere sites

App Service-verificatie beperkt aanvraagvervalsing tussen sites door clientaanvragen te inspecteren op de volgende voorwaarden:

  • Het is een POST verzoek dat is geverifieerd via een sessiecookie.
  • 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 Origin ontbreekt of bevindt zich niet in de geconfigureerde lijst met CORS-origins (Cross-Origin Resource Sharing).

Wanneer een aanvraag aan al deze voorwaarden voldoet, weigert App Service-verificatie deze automatisch. U kunt deze mitigatielogica omzeilen door uw externe domein toe te voegen aan de omleidingslijst in Instellingen>Verificatie>Verificatie-instellingen bewerken>Toegestane externe omleidings-URL's.

Overwegingen voor het gebruik van Azure Front Door

Wanneer u Azure App Service gebruikt met verificatie achter Azure Front Door of andere omgekeerde proxy's, kunt u de volgende acties overwegen.

Azure Front Door-caching uitschakelen

Azure Front Door-caching uitschakelen voor de verificatiewerkstroom.

Het Azure Front Door-eindpunt gebruiken voor omleidingen

App Service is meestal niet rechtstreeks toegankelijk wanneer deze beschikbaar wordt gesteld door Azure Front Door. U kunt dit gedrag bijvoorbeeld voorkomen door App Service beschikbaar te maken met behulp van Azure Private Link in Azure Front Door Premium. Om te voorkomen dat de verificatiewerkstroom verkeer rechtstreeks omleidt naar App Service. Zie Omleidings-URI voor meer informatie.

Zorg ervoor dat App Service de juiste omleidings-URI gebruikt

In sommige configuraties gebruikt App Service de FQDN (Fully Qualified Domain Name) als de omleidings-URI in plaats van de FQDN van Azure Front Door. Deze configuratie veroorzaakt een probleem wanneer de client wordt omgeleid naar App Service in plaats van Azure Front Door. Wijzig dit door forwardProxy in te stellen op Standard zodat App Service de X-Forwarded-Host-header respecteert die door Azure Front Door is ingesteld.

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

U kunt de forwardProxy configuratie niet wijzigen met behulp van Azure Portal. Je moet az rest gebruiken.

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

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

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

Verwante inhoud

Zie voor meer informatie over App Service-verificatie:

Zie voor voorbeelden: