Sdílet prostřednictvím

Ověřování a autorizace ve službě Aplikace Azure a Azure Functions

Azure App Service poskytuje integrované ověřování (přihlašování uživatelů) a autorizaci (poskytování přístupu k zabezpečeným datům). Tyto funkce se někdy nazývají Easy Auth. Můžete je použít k přihlášení uživatelů a přístupu k datům napsáním malého nebo žádného kódu ve webové aplikaci, rozhraní RESTful API, mobilním serveru a funkcích.

Tento článek popisuje, jak app Service pomáhá zjednodušit ověřování a autorizaci pro vaši aplikaci.

Důvody použití integrovaného ověřování

K implementaci ověřování a autorizace můžete použít funkce zabezpečení ve webovém rozhraní, které si zvolíte, nebo můžete napsat vlastní nástroje. Implementace zabezpečeného řešení pro ověřování a autorizaci může znamenat značné úsilí. Potřebujete dodržovat oborové osvědčené postupy a standardy. Musíte také zajistit, aby vaše řešení zůstalo aktuální s nejnovějšími aktualizacemi zabezpečení, protokolu a prohlížeče.

Integrované funkce služby App Service a Azure Functions vám můžou ušetřit čas a úsilí tím, že poskytují předem vytvořené ověřování s federovanými zprostředkovateli identit, abyste se mohli soustředit na zbytek aplikace.

Se službou App Service můžete integrovat možnosti ověřování do webové aplikace nebo rozhraní API, aniž byste je implementovali sami. Tato funkce je integrovaná přímo do platformy a nevyžaduje žádný konkrétní jazyk, sadu SDK, znalosti zabezpečení ani kód. Můžete ho integrovat s několika poskytovateli přihlašování, jako jsou Microsoft Entra, Facebook, Google a X.

Vaše aplikace může potřebovat podporovat složitější scénáře, jako je integrace sady Visual Studio nebo přírůstkové vyjádření souhlasu. Pro podporu těchto scénářů je k dispozici několik řešení ověřování. Další informace najdete v tématu Scénáře ověřování a doporučení.

Zprostředkovatelé identit

App Service používá federovanou identitu. Zprostředkovatel identity od Microsoftu nebo jiné společnosti spravuje uživatelské identity a autentizační tok za vás. Ve výchozím nastavení jsou k dispozici následující zprostředkovatelé identity:

Poskytovatel Koncový bod přihlášení Příručka s postupy
Microsoft Entra /.auth/login/aad Přihlášení k platformě služby App Service Microsoft Entra
Facebook /.auth/login/facebook Přihlášení k Facebooku ve službě App Service
Google /.auth/login/google Přihlášení Ke službě App Service Google
X /.auth/login/x Přihlášení ke službě App Service X
GitHub /.auth/login/github Přihlášení ke službě App Service na GitHubu
Jablko /.auth/login/apple Přihlášení ke službě App Service prostřednictvím přihlášení Apple (Preview)
Libovolný zprostředkovatel OpenID Connect /.auth/login/<providerName> Přihlášení ke službě App Service OpenID Connect

Když tuto funkci nakonfigurujete u některého z těchto poskytovatelů, bude jeho přihlašovací koncový bod dostupný pro ověřování uživatelů a ověření ověřovacích tokenů od zprostředkovatele. Uživatelům můžete poskytnout libovolný počet těchto možností přihlášení.

Důležité informace o používání integrovaného ověřování

Povolení integrovaného ověřování způsobí automatické přesměrování všech požadavků na vaši aplikaci na HTTPS bez ohledu na nastavení konfigurace služby App Service k vynucení HTTPS. Toto automatické přesměrování můžete zakázat pomocí requireHttps nastavení v konfiguraci V2. Doporučujeme ale dál používat PROTOKOL HTTPS a zajistit, aby se nikdy nepřesílaly žádné tokeny zabezpečení přes nezabezpečená připojení HTTP.

Službu App Service můžete použít k autentizaci, a to buď s omezením přístupu k obsahu vašeho webu a rozhraním API, nebo bez něj. Nastavte omezení přístupu v části Nastavení>Ověřování>Nastavení ověřování ve vaší webové aplikaci:

  • Pokud chcete omezit přístup aplikace jenom na ověřené uživatele, nastavte akci, která se má provést, když se požadavek neověří pro přihlášení pomocí některého z nakonfigurovaných zprostředkovatelů identity.
  • Pokud chcete ověřit přístup, ale neomezovat přístup, nastavte akci, která se má provést, když požadavek není ověřený tak, aby povoloval anonymní žádosti (žádná akce).

Důležité

Každé registraci aplikace byste měli udělit vlastní oprávnění a souhlas. Vyhněte se sdílení oprávnění mezi prostředími pomocí samostatných registrací aplikací pro samostatné sloty nasazení. Při testování nového kódu může tento postup pomoct zabránit problémům v ovlivnění produkční aplikace.

Jak to funguje

Architektura funkcí

Komponenta middlewaru pro ověřování a autorizaci je funkce platformy, která běží na stejném virtuálním počítači jako vaše aplikace. Když ji povolíte, každý příchozí požadavek HTTP projde danou komponentou před tím, než ji vaše aplikace zpracuje.

Diagram architektury znázorňující proces v sandboxu webu, který komunikuje se zprostředkovateli identity před povolením provozu do nasazené lokality

Middleware platformy zpracovává několik věcí pro vaši aplikaci:

  • Ověřuje uživatele a klienty pomocí určených zprostředkovatelů identity.
  • Ověřuje, ukládá a aktualizuje tokeny OAuth, které vydali nakonfigurovaní zprostředkovatelé identity.
  • Spravuje autentizovanou relaci.
  • Vloží informace o identitě do hlaviček požadavků HTTP.

Modul běží odděleně od kódu aplikace. Můžete ho nakonfigurovat pomocí nastavení Azure Resource Manageru nebo pomocí konfiguračního souboru. Nejsou vyžadovány žádné sady SDK, konkrétní programovací jazyky ani změny kódu aplikace.

Architektura funkcí ve Windows (nasazení bez kontejneru)

Modul ověřování a autorizace běží jako nativní modul IIS ve stejném sandboxu jako vaše aplikace. Když ji povolíte, každý příchozí požadavek HTTP ho projde před tím, než ji vaše aplikace zpracuje.

Architektura funkcí v Linuxu a kontejnerech

Modul ověřování a autorizace běží v samostatném kontejneru, který je izolovaný od kódu vaší aplikace. Modul používá vzor ambasadora k interakci s příchozím provozem, aby prováděl podobné funkce jako ve Windows. Protože se nespustí v procesu, není možná přímá integrace s konkrétními jazykovými architekturami. Důležité informace, které vaše aplikace potřebuje, se ale předávají v hlavičce požadavků.

Průběh ověřování

Tok ověřování je stejný pro všechny poskytovatele. Liší se v závislosti na tom, jestli se chcete přihlásit pomocí sady SDK poskytovatele:

  • Bez sady SDK poskytovatele: Aplikace deleguje federované přihlášení službě App Service. Toto delegování se obvykle týká aplikací prohlížeče, které můžou uživateli prezentovat přihlašovací stránku poskytovatele. Kód serveru spravuje proces přihlašování, takže se také označuje jako tok řízený serverem nebo tok serveru.

    Tento případ platí pro aplikace prohlížeče a mobilní aplikace, které k ověřování používají vložený prohlížeč.

  • Pomocí sady SDK poskytovatele: Aplikace přihlašuje uživatele k poskytovateli manuálně. Potom odešle ověřovací token do služby App Service k ověření. Tento proces se obvykle týká aplikací bez prohlížeče, které uživateli nemůžou prezentovat přihlašovací stránku poskytovatele. Kód aplikace spravuje proces přihlašování, takže se také označuje jako tok řízený klientem nebo tok klienta.

    Tento případ platí pro rozhraní REST API, Azure Functions a klienty prohlížeče JavaScriptu, a to kromě aplikací prohlížeče, které potřebují větší flexibilitu v procesu přihlašování. Platí také pro nativní mobilní aplikace, které přihlašují uživatele pomocí sady SDK poskytovatele.

Volání z důvěryhodné aplikace prohlížeče ve službě App Service do jiného rozhraní REST API ve službě App Service nebo Azure Functions je možné ověřit prostřednictvím toku řízeného serverem. Další informace najdete v tématu Přizpůsobení přihlašování a odhlašování v ověřování služby Azure App Service.

Následující tabulka ukazuje kroky toku ověřování.

Krok Bez sady SDK poskytovatele S využitím SDK poskytovatele
1. Přihlaste se uživatele. Zprostředkovatel přesměruje klienta na /.auth/login/<provider>. Klientský kód přihlásí uživatele přímo prostřednictvím sady SDK poskytovatele a obdrží ověřovací token. Další informace najdete v dokumentaci poskytovatele.
2. Post-autentizace Zprostředkovatel přesměruje klienta na /.auth/login/<provider>/callback. Kód klienta odešle token od zprostředkovatele k /.auth/login/<provider> pro ověření.
Vytvořit ověřenou relaci Služba App Service přidá do odpovědi ověřený soubor cookie. App Service vrátí klientskému kódu vlastní ověřovací token.
4. Obsluha ověřeného obsahu Klient zahrnuje ověřovací soubor cookie v následných požadavcích (automaticky zpracovaný prohlížečem). Kód klienta zobrazí ověřovací token v X-ZUMO-AUTH hlavičce.

V klientských prohlížečích může App Service automaticky směrovat všechny neověřené uživatele na /.auth/login/<provider>. Uživatele můžete také prezentovat s jedním nebo více /.auth/login/<provider> odkazy pro přihlášení k aplikaci pomocí jejich zvoleného poskytovatele.

Chování autorizace

Na webu Azure Portal můžete nakonfigurovat službu App Service s různými chováními, když se příchozí požadavek neověří. Následující části popisují možnosti.

Důležité

Ve výchozím nastavení tato funkce poskytuje pouze ověřování, nikoli autorizaci. Kromě kontrol, které tady nakonfigurujete, může vaše aplikace i nadále potřebovat provést rozhodnutí o autorizaci.

Omezený přístup

  • Povolit neověřené požadavky: Tato možnost přesouvá autorizaci neověřeného provozu do kódu vaší aplikace. U ověřených požadavků služba App Service předává také ověřovací informace v hlavičce HTTP.

    Tato možnost poskytuje větší flexibilitu při zpracování anonymních požadavků. Umožňuje například uživatelům prezentovat více poskytovatelů přihlašování. Musíte ale napsat kód.

  • Vyžadovat ověření: Tato možnost odmítne veškerý neověřený provoz do vaší aplikace. Konkrétní akce, která se má provést, se zadává v části Neověřené žádosti dále v tomto článku.

    Pomocí této možnosti nemusíte v aplikaci psát žádný ověřovací kód. Pomocí kontroly deklarací identity uživatele můžete provést podrobnější autorizaci, jako je autorizace specifické pro role.

    Upozornění

    Omezení přístupu tímto způsobem platí pro všechna volání vaší aplikace, která nemusí být žádoucí pro aplikace, které chtějí veřejně dostupnou domovskou stránku, stejně jako v mnoha jednostrákových aplikacích. Pokud jsou potřeba výjimky, musíte nakonfigurovat vyloučené cesty v konfiguračním souboru.

    Poznámka:

    Při použití zprostředkovatele identity Microsoftu pro uživatele ve vaší organizaci je výchozím chováním, že každý uživatel ve vašem tenantovi Microsoft Entra může požádat o token pro vaši aplikaci. Aplikaci v Microsoft Entra můžete nakonfigurovat, pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů. App Service také nabízí některé základní integrované kontroly autorizace, které mohou pomoct s některými ověřeními. Další informace o autorizaci v Microsoft Entra najdete v tématu Základy autorizace Microsoft Entra.

Pokud používáte zprostředkovatele identity Microsoftu pro uživatele ve vaší organizaci, výchozí chování je, že každý uživatel ve vašem tenantovi Microsoft Entra může požádat o token pro vaši aplikaci. Aplikaci v Microsoft Entra můžete nakonfigurovat, pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů. App Service také nabízí některé základní integrované kontroly autorizace , které můžou pomoct s některými ověřeními. Další informace o autorizaci v Microsoft Entra najdete v tématu Základy autorizace Microsoft Entra.

Neověřené požadavky

  • HTTP 302 Nalezeno přesměrování: doporučeno pro webové stránky: Přesměrovává akci na jednoho z nakonfigurovaných poskytovatelů identity. V těchto případech se klient prohlížeče přesměruje na /.auth/login/<provider> poskytovatele, kterého zvolíte.
  • HTTP 401 Neautorizováno: Doporučeno pro rozhraní API: Vrátí HTTP 401 Unauthorized odpověď, pokud anonymní požadavek pochází z nativní mobilní aplikace. Zamítnutí můžete také nakonfigurovat tak, aby bylo HTTP 401 Unauthorized pro všechny požadavky.
  • HTTP 403 Zakázáno: Nastaví odmítnutí tak, aby bylo HTTP 403 Forbidden pro všechny požadavky.
  • HTTP 404 Nenalezena: Nakonfiguruje zamítnutí HTTP 404 Not found pro všechny požadavky.

Úložiště tokenů

App Service poskytuje integrované úložiště tokenů. Úložiště tokenů je úložiště tokenů, které jsou přidružené uživatelům vašich webových aplikací, rozhraní API nebo nativních mobilních aplikací. Když povolíte ověřování u libovolného zprostředkovatele, bude toto úložiště tokenů pro vaši aplikaci okamžitě dostupné.

Pokud kód aplikace potřebuje přístup k datům od těchto zprostředkovatelů jménem uživatele, obvykle musíte napsat kód pro shromažďování, ukládání a aktualizaci těchto tokenů ve vaší aplikaci. Akce můžou zahrnovat:

  • Zveřejněte na časové ose autentizovaného uživatele na Facebooku.
  • Přečtěte si firemní data uživatele pomocí rozhraní Microsoft Graph API.

V úložišti tokenů stačí načíst tokeny , když je potřebujete, a dát službě App Service vědět, aby je aktualizoval, když se stanou neplatnými.

Identifikační tokeny, přístupové tokeny a obnovovací tokeny se ukládají do mezipaměti pro ověřenou relaci. Přístup k nim má jenom přidružený uživatel.

Pokud v aplikaci nepotřebujete pracovat s tokeny, můžete zakázat úložiště tokenů na stránceOvěřování> vaší aplikace.

Protokolování a sledování

Pokud povolíte záznamy aplikace, ověřování a stopy povolení se zobrazí přímo v souborech protokolu. Pokud se zobrazí chyba ověřování, kterou jste nečekali, můžete snadno najít všechny podrobnosti v existujících protokolech aplikace.

Pokud povolíte trasování neúspěšných požadavků, můžete přesně zjistit, jakou roli může v neúspěšném požadavku hrát modul ověřování a autorizace. V protokolech trasování vyhledejte odkazy na modul s názvem EasyAuthModule_32/64.

Zmírnění útoků typu cross-site request forgery

Ověřování služby App Service zmírňuje padělání požadavků mezi různými weby kontrolováním, zda požadavky klientů splňují následující podmínky.

  • Jedná se o POST požadavek, který se ověřil prostřednictvím souboru cookie relace.
  • Požadavek pochází ze známého prohlížeče, jak určuje hlavička HTTP User-Agent .
  • Hlavička HTTP Origin nebo HTTP Referer chybí nebo není v nakonfigurovaného seznamu schválených externích domén pro přesměrování.
  • Hlavička HTTP Origin chybí nebo není v nakonfigurovaného seznamu zdrojů sdílení prostředků mezi zdroji (CORS).

Když požadavek splňuje všechny tyto podmínky, ověřování služby App Service ho automaticky odmítne. Tuto logiku zmírnění můžete obejít tak, že přidáte svou externí doménu do seznamu přesměrování v Nastavení>Ověřování>Upravit nastavení ověřování>Povolené externí přesměrovací URL.

Důležité informace o používání služby Azure Front Door

Pokud používáte Službu Azure App Service s ověřováním za Azure Front Doorem nebo jinými reverzními proxy servery, zvažte následující akce.

Zakázání ukládání do mezipaměti služby Azure Front Door

Zakažte ukládání do mezipaměti služby Azure Front Door pro pracovní postup ověřování.

Použití koncového bodu služby Azure Front Door pro přesměrování

Služba App Service není obvykle přístupná přímo, když je vystavená službou Azure Front Door. Toto chování můžete zabránit například zveřejněním služby App Service pomocí služby Azure Private Link ve službě Azure Front Door Premium. Chcete-li zabránit tomu, aby pracovní postup ověřování přesměrovával provoz přímo zpět do služby App Service. Další informace viz Redirect URI.

Ujistěte se, že App Service používá správné URI přesměrování.

V některých konfiguracích služba App Service používá jako identifikátor URI přesměrování plně kvalifikovaný název domény (FQDN) místo plně kvalifikovaného názvu domény služby Azure Front Door. Tato konfigurace způsobí problém, když se klient přesměruje do služby App Service místo služby Azure Front Door. Pokud ji chcete změnit, nastavte forwardProxy na Standard, aby služba App Service respektovala hlavičku nastavenou službou Azure Front Door.

Jiné reverzní proxy servery, jako je Azure Application Gateway nebo produkty jiných společností než Microsoft, můžou používat jiné hlavičky a potřebují jiné forwardProxy nastavení.

Konfiguraci nemůžete změnit forwardProxy pomocí webu Azure Portal. Potřebujete použít az rest.

Nastavení exportu

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

Aktualizace nastavení

Hledat:

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

Ujistěte se, že convention je nastaveno na Standard, aby byla respektována hlavička X-Forwarded-Host, kterou Azure Front Door používá.

Nastavení importu

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

Související obsah

Další informace o ověřování ve službě App Service najdete tady:

Ukázky najdete tady: