Prozkoumání ověřování a autorizace ve službě App Service

Dokončeno

služba Aplikace Azure poskytuje integrovanou podporu ověřování a autorizace. Uživatele a přístup k datům můžete přihlásit tak, že do webové aplikace, rozhraní RESTful API, mobilního back-endu nebo Azure Functions napíšete minimální nebo žádný kód.

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

K ověřování a autorizaci se nevyžaduje použití služby App Service. Řada webových architektur je součástí funkcí zabezpečení a pokud chcete, můžete je použít. Pokud potřebujete větší flexibilitu než služba App Service, můžete také napsat vlastní nástroje.

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 různé možnosti ověřování, aniž byste je implementovali sami.
• Ověřování je integrované přímo do platformy a nevyžaduje žádný konkrétní jazyk, sadu SDK, znalosti zabezpečení ani kód.
• Můžete se integrovat s několika zprostředkovateli přihlášení. Například Microsoft Entra ID, Facebook, Google, X.

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 identity platform	/.auth/login/aad	Přihlášení ke službě App Service Microsoft Identity Platform
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/twitter	Přihlášení ke službě App Service X
Libovolný zprostředkovatel OpenID Connect	/.auth/login/<providerName>	Přihlášení ke službě App Service OpenID Connect
GitHub	/.auth/login/github	Přihlášení ke službě App Service na GitHubu

Když povolíte ověřování a autorizaci u některého z těchto poskytovatelů, bude jeho přihlašovací koncový bod k dispozici 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í.

Jak to funguje

Modul ověřování a autorizace běží ve stejném sandboxu jako kód vaší aplikace. Pokud je tato možnost povolená, před předáním kódu vaší aplikace prochází každý příchozí požadavek HTTP. Tento modul zpracovává několik věcí pro vaši aplikaci:

• Ověřuje uživatele a klienty pomocí zadaného zprostředkovatele identity.
• Ověřuje, ukládá a aktualizuje tokeny OAuth vydané nakonfigurovaným zprostředkovatelem identity.
• 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.

Poznámka:

V Linuxu a kontejnerech se modul ověřování a autorizace spouští v samostatném kontejneru izolovaném od kódu vaší aplikace. Vzhledem k tomu, že neběží v procesu, není možná přímá integrace s konkrétními jazykovými architekturami.

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. 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řihlášení a označuje se jako tok řízený serverem nebo tok serveru.

• 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í a označuje se jako tok řízený klientem nebo tok klienta. To platí pro rozhraní REST API, Azure Functions, klienty prohlížeče JavaScriptu a nativní mobilní aplikace, které přihlašují uživatele pomocí sady SDK poskytovatele.

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

Krok	Bez sady SDK zprostředkovatele	S využitím sady SDK zprostředkovatele
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.
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í.
Vytvoření 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.
Obsluha ověřeného obsahu	Klient zahrnuje ověřovací soubor cookie v následných požadavcích (automaticky zpracovávaný prohlížečem).	Klientský kód zobrazí ověřovací token v X-ZUMO-AUTH hlavičce (automaticky zpracovávané klientskými sadami SDK Mobile Apps).

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

Na webu Azure Portal můžete nakonfigurovat službu App Service s mnoha chováními, když se příchozí požadavek neověří.

• Povolit neověřené požadavky: Tato možnost znemožní 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 uživatelům prezentovat více poskytovatelů přihlašování.

• Vyžadovat ověření: Tato možnost odmítne veškerý neověřený provoz do vaší aplikace. Toto odmítnutí může být akce přesměrování 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. 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 nebo HTTP 401 UnauthorizedHTTP 403 Forbidden pro všechny požadavky.

  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.

Ú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é.

Protokolování a trasování

Pokud povolíte protokolování aplikace, budou se trasování ověřování a autorizace shromažďovat 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.