Verificatie en autorisatie verkennen in App Service
Azure-app Service biedt ingebouwde ondersteuning voor verificatie en autorisatie. U kunt gebruikers aanmelden en toegang krijgen tot gegevens door minimale of geen code te schrijven in uw web-app, RESTful-API, mobiele back-end of Azure Functions.
Waarom de ingebouwde verificatie gebruiken?
U hoeft App Service niet te gebruiken voor verificatie en autorisatie. Veel webframeworks zijn gebundeld met beveiligingsfuncties en u kunt ze desgewenst gebruiken. Als u meer flexibiliteit nodig hebt dan App Service biedt, kunt u ook uw eigen hulpprogramma's schrijven.
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 verschillende verificatiemogelijkheden integreren in uw web-app of API zonder ze zelf te implementeren.
- Verificatie is rechtstreeks ingebouwd in het platform en vereist geen specifieke taal, SDK, beveiligingsexpertise of code.
- U kunt integreren met meerdere aanmeldingsproviders. Bijvoorbeeld Microsoft Entra ID, Facebook, Google, X.
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 bij het Microsoft Entra-platform van App Service |
/.auth/login/facebook |
Aanmelding bij App Service Facebook | |
/.auth/login/google |
Google-aanmelding voor App Service | |
| X | /.auth/login/x |
App Service X-aanmelding |
| Elke OpenID Connect-provider | /.auth/login/<providerName> |
Aanmelding bij App Service OpenID Connect |
| GitHub | /.auth/login/github |
Aanmelding bij App Service GitHub |
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.
Hoe het werkt
Het onderdeel verificatie- en autorisatie-middleware is een functie van het platform dat wordt uitgevoerd op dezelfde VM als uw toepassing. Wanneer deze functie is ingeschakeld, wordt elke binnenkomende HTTP-aanvraag doorgegeven voordat deze wordt verwerkt door uw toepassing.
De platform-middleware verwerkt verschillende dingen voor uw app:
- Verifieert gebruikers en clients met de opgegeven id-provider
- Hiermee worden OAuth-tokens gevalideerd, opgeslagen en vernieuwd die zijn uitgegeven door de geconfigureerde id-provider
- 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.
Notitie
In Linux en containers wordt de verificatie- en autorisatiemodule uitgevoerd in een afzonderlijke container, geïsoleerd van uw toepassingscode. Omdat het niet in proces wordt uitgevoerd, is er geen directe integratie met specifieke taalframeworks mogelijk.
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. Deze overdracht is meestal het geval bij browser-apps, die de aanmeldingspagina van de provider aan de gebruiker kunnen presenteren. De servercode beheert het aanmeldingsproces en wordt ook wel servergestuurde stroom of serverstroom genoemd.
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 en wordt aangeduid als clientgestuurde stroom of clientstroom. Dit is van toepassing op REST API's, Azure Functions, JavaScript-browserclients en systeemeigen mobiele apps die gebruikers aanmelden met behulp van de SDK van de provider.
In de volgende tabel ziet u de stappen van de verificatiestroom.
| Stap | Zonder provider-SDK | Met provider-SDK |
|---|---|---|
| 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. |
| Na verificatie | Provider stuurt de client om naar /.auth/login/<provider>/callback. |
Clientcode plaatst token van provider naar /.auth/login/<provider> voor validatie. |
| Geverifieerde sessie tot stand brengen | App Service voegt geverifieerde cookie toe aan het antwoord. | App Service retourneert een eigen verificatietoken naar clientcode. |
| Geverifieerde inhoud leveren | Client bevat verificatiecookies in volgende aanvragen (automatisch verwerkt door de browser). | Clientcode presenteert verificatietoken in X-ZUMO-AUTH de header (automatisch verwerkt door Mobile Apps-client-SDK's). |
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
In Azure Portal kunt u App Service configureren met veel gedrag wanneer een binnenkomende aanvraag niet wordt geverifieerd.
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 meerdere aanmeldingsproviders aan uw gebruikers presenteren.
Verificatie vereisen: met deze optie wordt niet-geverifieerd verkeer naar uw toepassing geweigerd. Deze afwijzing kan een omleidingsactie zijn naar een van de geconfigureerde id-providers. In deze gevallen wordt een browserclient omgeleid naar
/.auth/login/<provider>de provider die u kiest. Als de anonieme aanvraag afkomstig is van een systeemeigen mobiele app, is het geretourneerde antwoord eenHTTP 401 Unauthorized. U kunt de afwijzing ook zo configureren dat deze eenHTTP 401 UnauthorizedofHTTP 403 Forbiddenvoor alle aanvragen is.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.
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.
Logboekregistratie en tracering
Als u toepassingslogboeken inschakelt, worden verificatie- en autorisatietraceringen rechtstreeks in uw logboekbestanden verzameld. Als u een verificatiefout ziet die u niet had verwacht, kunt u gemakkelijk alle details vinden door in uw bestaande toepassingslogboeken te zoeken.