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

Poznámka:

Od 1. června 2024 budou mít všechny nově vytvořené aplikace App Service možnost vygenerovat jedinečný výchozí název hostitele pomocí zásad <app-name>-<random-hash>.<region>.azurewebsites.netvytváření názvů . Stávající názvy aplikací zůstanou beze změny.

Příklad: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Další podrobnosti najdete v tématu Jedinečný výchozí název hostitele pro prostředek služby App Service.

služba Aplikace Azure poskytuje integrované možnosti ověřování a autorizace (někdy označované jako Snadné ověřování), takže se můžete přihlásit k uživatelům a datům přístupu tak, že do webové aplikace, rozhraní RESTful API a mobilního back-endu napíšete minimální nebo žádný kód.Azure Functions. Tento článek popisuje, jak app Service pomáhá zjednodušit ověřování a autorizaci pro vaši aplikaci.

Proč používat integrované ověřování?

Tuto funkci nemusíte používat k ověřování a autorizaci. Ve webovém rozhraní, které si zvolíte, můžete použít sbalené funkce zabezpečení nebo můžete napsat vlastní nástroje. Budete ale muset zajistit, aby vaše řešení zůstalo aktuální s nejnovějšími aktualizacemi zabezpečení, protokolu a prohlížeče.

Implementace zabezpečeného řešení pro ověřování (přihlášení uživatelů) a autorizace (poskytování přístupu k zabezpečeným datům) může výrazně znamenat značné úsilí. Musíte se ujistit, že dodržujete osvědčené postupy a standardy v oboru a udržujete implementaci v aktualizovaném stavu. Integrovaná funkce ověřování pro App Service a Azure Functions vám může ušetřit čas a úsilí tím, že poskytuje předem připravená ověřování s federovanými zprostředkovateli identit, což vám umožní soustředit se na zbytek vaší aplikace.

• služba Aplikace Azure umožňuje integrovat do webové aplikace nebo rozhraní API celou řadu možností ověřování, aniž byste je implementovali sami.
• Je integrovaná přímo do platformy a nevyžaduje žádný konkrétní jazyk, sadu SDK, znalosti zabezpečení ani žádný kód, který by bylo možné využít.
• Můžete se integrovat s několika zprostředkovateli přihlášení. Například Microsoft Entra, Facebook, Google, 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ý souhlas. Pro podporu těchto scénářů je k dispozici několik různých řešení ověřování. Další informace najdete ve scénářích identit.

Zprostředkovatelé identit

App Service používá federovanou identitu, ve které za vás spravuje identity uživatelů a tok ověřování třetí strany. Ve výchozím nastavení jsou k dispozici následující zprostředkovatelé identity:

Poskytovatel	Koncový bod přihlášení	Pokyny k návodům
Microsoft Entra	/.auth/login/aad	Přihlášení k platformě 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
Přihlášení pomocí Apple	/.auth/login/apple	Přihlášení ke službě App Service pomocí 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í této funkce 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 nastavení můžete zakázat pomocí requireHttps nastavení v konfiguraci V2. Doporučujeme ale držet se protokolu HTTPS a měli byste zajistit, aby se žádné tokeny zabezpečení nepřesílaly přes nezabezpečené připojení HTTP.

App Service se dá použít k ověřování s obsahem webu a rozhraními API nebo bez omezení přístupu k obsahu webu a rozhraním API. Omezení přístupu je možné nastavit v části Nastavení ověřování ověřování>vaší webové aplikace. Pokud chcete omezit přístup aplikace jenom k ověřeným uživatelům, 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 provést ověření, ale neomezíte přístup, nastavte akci, která se provede, když se požadavek neověří na Povolit anonymní žádosti (bez 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, které mají vliv na produkční aplikaci.

Jak to funguje

Architektura funkcí

Tok ověřování

Chování autorizace

Úložiště tokenů

Protokolování a trasování

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ž je povolená, každý příchozí požadavek HTTP ho před zpracováním vaší aplikace projde.

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

• Ověřuje uživatele a klienty pomocí zadaných zprostředkovatelů identity.
• Ověřuje, ukládá a aktualizuje tokeny OAuth vydané nakonfigurovanými zprostředkovateli identit.
• Spravuje ověřenou relaci.
• Vloží informace o identitě do hlaviček požadavků HTTP.

Modul běží odděleně od kódu aplikace a dá se 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ž je povolená, každý příchozí požadavek HTTP ho před zpracováním vaší aplikace projde.

Architektura funkcí v Linuxu a kontejnerech

Modul ověřování a autorizace se spouští v samostatném kontejneru, který je izolovaný od kódu vaší aplikace. Pomocí vzoru ambasadora komunikuje s příchozím provozem, aby prováděl podobné funkce jako ve Windows. Vzhledem k tomu, že neběží v procesu, není možná přímá integrace s konkrétními jazykovými architekturami; relevantní informace, které vaše aplikace potřebuje, se ale předávají pomocí hlaviček požadavků, jak je vysvětleno níže.

Tok ověřování

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

• Bez sady SDK zprostředkovatele: Aplikace deleguje federované přihlašování do služby App Service. Obvykle se jedná o případ s aplikacemi prohlížeče, které můžou uživateli prezentovat přihlašovací stránku poskytovatele. Kód serveru spravuje proces přihlášení, 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č.
• Sada SDK zprostředkovatele: Aplikace přihlásí uživatele k poskytovateli ručně a pak odešle ověřovací token do služby App Service k ověření. Obvykle se jedná o aplikace bez prohlížeče, které nemůžou uživateli 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 také aplikace 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 pomocí toku řízeného serverem. Další informace najdete v tématu Přizpůsobení přihlášení a odhlášení.

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

Krok	Bez sady SDK zprostředkovatele	S využitím sady SDK zprostředkovatele
1. Přihlášení uživatele	Přesměruje klienta na /.auth/login/<provider>.	Klientský kód podepíše uživatele přímo pomocí sady SDK poskytovatele a obdrží ověřovací token. Informace najdete v dokumentaci poskytovatele.
2. Po ověření	Zprostředkovatel přesměruje klienta na /.auth/login/<provider>/callback.	Klientský kód publikuje token od zprostředkovatele k /.auth/login/<provider> ověření.
3. Navázání ověřené relace	Služba App Service přidá do odpovědi ověřený soubor cookie.	App Service vrátí do kódu klienta vlastní ověřovací token.
4. Obsluha ověřeného obsahu	Klient zahrnuje ověřovací soubor cookie v následných požadavcích (automaticky zpracovávaný prohlížečem).	Kód klienta představuje 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>. Můžete také prezentovat uživatele s jedním nebo více /.auth/login/<provider> odkazy pro přihlášení k vaší aplikaci pomocí jejich zvoleného poskytovatele.

Chování autorizace

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 muset provést rozhodnutí o autorizaci.

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

Omezení přístupu

• Povolte neověřené požadavky . Tato možnost odblokuje autorizaci neověřeného provozu do kódu 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 .

  Pomocí této možnosti nemusíte v aplikaci psát žádný ověřovací kód. Podrobná autorizace, jako je autorizace specifická pro roli, se dá zpracovat kontrolou deklarací identity uživatele (viz Deklarace identity uživatelů v Accessu).

  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.

  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.

Neověřené požadavky

• Http 302 Nalezeno přesměrování: Doporučeno pro akci Přesměrování webů na jednoho z nakonfigurovaných zprostředkovatelů identity. V těchto případech se klient prohlížeče přesměruje na /.auth/login/<provider> zprostředkovatele, který zvolíte.
• HTTP 401 Neautorizováno: Doporučuje se pro rozhraní API , pokud anonymní požadavek pochází z nativní mobilní aplikace, vrácená odpověď je HTTP 401 Unauthorized. Zamítnutí můžete také nakonfigurovat tak, aby bylo pro všechny požadavky.HTTP 401 Unauthorized
• HTTP 403 Zakázáno Konfiguruje zamítnutí jako pro HTTP 403 Forbidden všechny požadavky.
• Http 404 Nenalezena konfigurace zamítnutí pro HTTP 404 Not found všechny požadavky.

Úložiště tokenů

App Service poskytuje integrované úložiště tokenů, což je úložiště tokenů přidružených uživatelům 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 poskytovatelů jménem uživatele, například:

• post to the authenticated user's Facebook timeline
• čtení podnikových dat uživatele pomocí rozhraní Microsoft Graph API

Obvykle musíte napsat kód pro shromažďování, ukládání a aktualizaci těchto tokenů ve vaší aplikaci. 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.

Tokeny ID, přístupové tokeny a obnovovací tokeny se ukládají do mezipaměti pro ověřenou relaci a jsou přístupné jenom přidruženým uživatelem.

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

Protokolování a trasování

Pokud povolíte protokolování aplikace, uvidíte trasování ověřování a autorizace přímo v souborech protokolů. 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 mohl modul ověřování a autorizace hrát v neúspěšném požadavku. V protokolech trasování vyhledejte odkazy na modul s názvem EasyAuthModule_32/64.

Zmírnění rizik padělání požadavků mezi weby

Ověřování služby App Service zmírní CSRF kontrolou požadavků klientů na následující podmínky:

• Jedná se o požadavek POST, který se ověřil pomocí souboru cookie relace.
• Požadavek pochází ze známého prohlížeče (jak je určeno hlavičkou 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 původů CORS.

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

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

Při použití služby Aplikace Azure s ověřováním za Azure Front Doorem nebo jinými reverzními proxy servery je potřeba vzít v úvahu několik dalších věcí.

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

• Pro přesměrování použijte koncový bod služby Front Door.

  Služba App Service není obvykle přístupná přímo při zveřejnění přes Azure Front Door. To se dá zabránit například zveřejněním služby App Service prostřednictvím služby Private Link ve službě Azure Front Door Premium. Aby se zabránilo pracovnímu postupu ověřování přesměrování provozu zpět do služby App Service, je důležité nakonfigurovat aplikaci tak, aby se přesměrovává zpět na https://<front-door-endpoint>/.auth/login/<provider>/callback.

• Ujistěte se, že služba App Service používá správný identifikátor 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í místo plně kvalifikovaného názvu domény služby Front Door plně kvalifikovaný název domény služby App Service. To povede k problému, kdy se klient přesměruje do služby App Service místo služby Front Door. Pokud to chcete změnit, musí být nastavení nastavené tak, forwardProxy aby Standard služba App Service respektovala hlavičku nastavenou X-Forwarded-Host službou Azure Front Door.

  Jiné reverzní proxy servery, jako je Aplikace Azure lication Gateway nebo produkty třetích stran, můžou používat různé hlavičky a potřebují jiné nastavení forwardProxy.

  Tuto konfiguraci není možné provést prostřednictvím webu Azure Portal ještě dnes a je potřeba ji provést prostřednictvím az rest:

  Export nastavení

  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í

  Vyhledat

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

  a ujistěte se, že je nastavená tak, convention aby Standard respektovala hlavičku X-Forwarded-Host používanou službou Azure Front Door.

  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

Další materiály

• Postupy: Konfigurace služby App Service nebo aplikace Azure Functions tak, aby používala přihlášení k Microsoft Entra
• Přizpůsobení přihlášení a odhlášení

• Práce s tokeny OAuth a relacemi
• Přístup k deklaracím identity uživatelů a aplikací
• Konfigurace založená na souborech

Ukázky:

• Kurz: Přidání ověřování do webové aplikace spuštěné ve službě Aplikace Azure Service
• Kurz: Ověřování a autorizace koncových uživatelů ve službě Aplikace Azure Service (Windows nebo Linux)
• Integrace rozhraní .NET Core Aplikace Azure Service EasyAuth (třetí strana)
• Práce s ověřováním služby Aplikace Azure s .NET Core (třetí strana)