Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 |
/.auth/login/facebook |
Aanmelden bij App Service Facebook | |
/.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.
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 geldtHTTP 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-headerReferer
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:
- Uw App Service- of Azure Functions-app configureren voor het gebruik van Microsoft Entra-aanmelding
- aanmelden en afmelden in Azure App Service-verificatie aanpassen
- Werken met OAuth-tokens in Azure App Service-verificatie
- Werken met gebruikersidentiteiten in Azure App Service-verificatie
- Configuratie op basis van bestanden in Azure App Service-verificatie
Zie voor voorbeelden:
- Quickstart: App-verificatie toevoegen aan uw web-app die wordt uitgevoerd in Azure App Service
- Zelfstudie: Gebruikers van begin tot eind verifiëren en autoriseren in Azure App Service
- .NET Core-integratie van Azure AppService Easy Auth (niet-Microsoft GitHub-inhoud)
- Azure App Service-verificatie werkend krijgen met .NET Core (niet-Microsoft GitHub-inhoud)