Ověřování a autorizace v Azure App Service a Azure FunctionsAuthentication and authorization in Azure App Service and Azure Functions

Azure App Service poskytuje integrovanou podporu ověřování a autorizace, takže se můžete přihlašovat uživatelům a přistupovat k datům tak, že ve své webové aplikaci, rozhraní RESTful API a mobilním back-endu napíšete minimální nebo žádný kód a také Azure Functions.Azure App Service provides built-in authentication and authorization support, so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. Tento článek popisuje, jak App Service pomáhá zjednodušit ověřování a autorizaci pro vaši aplikaci.This article describes how App Service helps simplify authentication and authorization for your app.

Zabezpečené ověřování a autorizace vyžadují důkladné porozumění zabezpečení, včetně federace, šifrování, správy webových tokenů JSON (Jwt) , typů udělenía tak dále.Secure authentication and authorization require deep understanding of security, including federation, encryption, JSON web tokens (JWT) management, grant types, and so on. App Service poskytuje tyto nástroje, díky kterým můžete věnovat více času a energii na poskytování obchodních hodnot vašemu zákazníkovi.App Service provides these utilities so that you can spend more time and energy on providing business value to your customer.

Důležité

Tuto funkci nemusíte používat k ověřování a autorizaci.You're not required to use this feature for authentication and authorization. Ve vaší webové architektuře můžete použít sady funkcí zabezpečení, nebo můžete napsat vlastní nástroje.You can use the bundled security features in your web framework of choice, or you can write your own utilities. Mějte ale na paměti, že Chrome 80 provádí zásadní změny v implementaci SameSite for soubory cookie (Datum vydání v březnu 2020) a vlastní vzdálené ověřování nebo jiné scénáře, které se spoléhají na odesílání souborů cookie mezi weby, se můžou při aktualizaci prohlížečů klienta Chrome poškodit.However, keep in mind that Chrome 80 is making breaking changes to its implementation of SameSite for cookies (release date around March 2020), and custom remote authentication or other scenarios that rely on cross-site cookie posting may break when client Chrome browsers are updated. Alternativní řešení je složité, protože potřebuje podporovat různá chování SameSite pro různé prohlížeče.The workaround is complex because it needs to support different SameSite behaviors for different browsers.

ASP.NET Core 2,1 a novější verze hostované pomocí App Service jsou již pro tuto zásadní změnu opraveny a odpovídajícím způsobem zpracovávat Chrome 80 a starší prohlížeče.The ASP.NET Core 2.1 and above versions hosted by App Service are already patched for this breaking change and handle Chrome 80 and older browsers appropriately. Kromě toho byla na App Service instance v průběhu ledna 2020 stejná oprava pro ASP.NET Framework 4.7.2.In addition, the same patch for ASP.NET Framework 4.7.2 has been deployed on the App Service instances throughout January 2020. Další informace najdete v tématu Azure App Service aktualizace souboru cookie SameSite.For more information, see Azure App Service SameSite cookie update.

Poznámka

Funkce ověřování/autorizace se také někdy označuje jako "snadné ověření".The Authentication/Authorization feature is also sometimes referred to as "Easy Auth".

Poznámka

Povolení této funkce způsobí, že všechny nezabezpečené požadavky HTTP na vaši aplikaci budou automaticky přesměrovány na https bez ohledu na nastavení konfigurace App Service pro vymáhání protokolu HTTPS.Enabling this feature will cause all non-secure HTTP requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS. V případě potřeby ho můžete zakázat prostřednictvím requireHttps nastavení v konfiguračním souboru nastavení ověřování, ale je potřeba se ujistit, že se žádné tokeny zabezpečení nikdy nepřenášejí přes nezabezpečená připojení HTTP.If needed, you can disable this via the requireHttps setting in the auth settings configuration file, but you must then take care to ensure no security tokens ever get transmitted over non-secure HTTP connections.

Informace specifické pro nativní mobilní aplikace najdete v tématech ověřování a autorizace uživatelů pro mobilní aplikace s Azure App Service.For information specific to native mobile apps, see User authentication and authorization for mobile apps with Azure App Service.

Jak to fungujeHow it works

V systému WindowsOn Windows

Modul ověřování a autorizace se spouští ve stejném izolovaném prostoru jako váš kód aplikace.The authentication and authorization module runs in the same sandbox as your application code. Pokud je povolena, každý příchozí požadavek HTTP projde před tím, než bude zpracován kódem vaší aplikace.When it's enabled, every incoming HTTP request passes through it before being handled by your application code.

Diagram architektury znázorňující požadavky, které jsou zachyceny procesem v izolovaném prostoru webu, který komunikuje s poskytovateli identity před povolením provozu do nasazené lokality

Tento modul zpracovává několik věcí pro vaši aplikaci:This module handles several things for your app:

  • Ověřuje uživatele pomocí zadaného zprostředkovatele.Authenticates users with the specified provider
  • Ověří, ukládá a aktualizuje tokeny.Validates, stores, and refreshes tokens
  • Spravuje ověřenou relaci.Manages the authenticated session
  • Vloží informace o identitě do hlaviček požadavků.Injects identity information into request headers

Modul se spouští odděleně od kódu aplikace a je nakonfigurovaný pomocí nastavení aplikace.The module runs separately from your application code and is configured using app settings. Nevyžadují se žádné sady SDK, konkrétní jazyky ani změny kódu vaší aplikace.No SDKs, specific languages, or changes to your application code are required.

V kontejnerechOn Containers

Modul ověřování a autorizace se spouští v samostatném kontejneru izolovaném z kódu vaší aplikace.The authentication and authorization module runs in a separate container, isolated from your application code. Pomocí toho, co je známo jako vzorek velvyslanců, komunikuje s příchozím provozem, aby prováděl podobné funkce jako ve Windows.Using what's known as the Ambassador pattern, it interacts with the incoming traffic to perform similar functionality as on Windows. Protože se nespustí v procesu, není možné žádná přímá integrace s konkrétními jazykovými rozhraními. relevantní informace, které vaše aplikace potřebuje, se ale předávají pomocí hlaviček požadavků, jak je vysvětleno níže.Because it does not run in-process, no direct integration with specific language frameworks is possible; however, the relevant information that your app needs is passed through using request headers as explained below.

Deklarace identity uživatele nebo aplikaceUser/Application claims

Pro všechny jazykové architektury App Service vytvoří deklarace v příchozím tokenu (ať už jsou z ověřeného koncového uživatele nebo klientské aplikace), a to tak, že je vloží do hlaviček požadavku.For all language frameworks, App Service makes the claims in the incoming token (whether that be from an authenticated end user or a client application) available to your code by injecting them into the request headers. Pro App Service aplikace ASP.NET 4,6 naplní ClaimsPrincipal. Current deklarací identity ověřeného uživatele, takže můžete postupovat podle standardního vzoru kódu .NET, včetně [Authorize] atributu.For ASP.NET 4.6 apps, App Service populates ClaimsPrincipal.Current with the authenticated user's claims, so you can follow the standard .NET code pattern, including the [Authorize] attribute. Podobně pro aplikace PHP App Service naplní _SERVER['REMOTE_USER'] proměnnou.Similarly, for PHP apps, App Service populates the _SERVER['REMOTE_USER'] variable. Pro aplikace Java jsou deklarace identity dostupné z servlet Tomcat.For Java apps, the claims are accessible from the Tomcat servlet.

Pro Azure Functionsnení ClaimsPrincipal.Current vyplněno pro kód .NET, ale stále můžete najít deklarace identity uživatelů v hlavičce požadavku nebo získat ClaimsPrincipal objekt z kontextu požadavku nebo dokonce prostřednictvím parametru vazby.For Azure Functions, ClaimsPrincipal.Current is not populated for .NET code, but you can still find the user claims in the request headers, or get the ClaimsPrincipal object from the request context or even through a binding parameter. Další informace najdete v tématu Working with identity klientů .See working with client identities for more information.

Další informace najdete v tématu přístup k deklaracím uživatelů.For more information, see Access user claims.

Poznámka

V tuto chvíli ASP.NET Core aktuálně nepodporuje naplnění aktuálního uživatele funkcí ověřování/autorizace.At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature. Existují však některé třetí strany Open Source komponenty middlewaru, které vám pomůžou tuto mezeru vyplnit.However, some 3rd party, open source middleware components do exist to help fill this gap.

Úložiště tokenůToken store

App Service poskytuje integrované úložiště tokenů, což je úložiště tokenů, které jsou přidružené k uživatelům webových aplikací, rozhraní API nebo nativních mobilních aplikací.App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. Pokud povolíte ověřování u libovolného poskytovatele, je úložiště tokenů hned dostupné pro vaši aplikaci.When you enable authentication with any provider, this token store is immediately available to your app. Pokud kód aplikace potřebuje přístup k datům z těchto poskytovatelů jménem uživatele, například:If your application code needs to access data from these providers on the user's behalf, such as:

  • odeslání příspěvku na časovou osu Facebooku ověřeného uživatelepost to the authenticated user's Facebook timeline
  • Přečtěte si podniková data uživatele pomocí rozhraní Microsoft Graph API.read the user's corporate data using the Microsoft Graph API

Obvykle je nutné napsat kód pro shromažďování, ukládání a aktualizaci těchto tokenů ve vaší aplikaci.You typically must write code to collect, store, and refresh these tokens in your application. V úložišti tokenů stačí načíst tokeny , když je potřebujete, a sdělit App Service, že je budou aktualizovat , jakmile se stanou neplatnými.With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.

Tokeny ID, přístupové tokeny a aktualizační tokeny jsou uloženy v mezipaměti pro ověřenou relaci a jsou přístupné pouze přidruženému uživateli.The ID tokens, access tokens, and refresh tokens are cached for the authenticated session, and they're accessible only by the associated user.

Pokud nepotřebujete v aplikaci pracovat s tokeny, můžete úložiště tokenů zakázat na stránce ověřování/autorizace vaší aplikace.If you don't need to work with tokens in your app, you can disable the token store in your app's Authentication / Authorization page.

Protokolování a trasováníLogging and tracing

Pokud povolíte protokolování aplikací, zobrazí se přímo v souborech protokolu trasování pro ověřování a autorizaci.If you enable application logging, you will see authentication and authorization traces directly in your log files. Pokud se zobrazí chyba ověřování, kterou jste neočekávali, můžete pohodlně vyhledat všechny podrobnosti, a to tak, že budete hledat v existujících protokolech aplikací.If you see an authentication error that you didn't expect, you can conveniently find all the details by looking in your existing application logs. Pokud povolíte trasování chybných požadavků, vidíte přesně to, jakou roli se modul ověřování a autorizace mohl přehrát v neúspěšném požadavku.If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. V protokolech trasování vyhledejte odkazy na modul s názvem EasyAuthModule_32/64 .In the trace logs, look for references to a module named EasyAuthModule_32/64.

Zprostředkovatelé identitIdentity providers

App Service používá federované identity, ve kterém poskytovatel identity od jiného výrobce spravuje identity uživatelů a tok ověřování za vás.App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. Ve výchozím nastavení je dostupných pět zprostředkovatelů identity:Five identity providers are available by default:

PoskytovatelProvider Koncový bod přihlášeníSign-in endpoint
Azure Active DirectoryAzure Active Directory /.auth/login/aad
Účet MicrosoftMicrosoft Account /.auth/login/microsoftaccount
FacebookFacebook /.auth/login/facebook
GoogleGoogle /.auth/login/google
TwitterTwitter /.auth/login/twitter
Libovolný poskytovatel OpenID Connect (Preview)Any OpenID Connect provider (preview) /.auth/login/<providerName>

Pokud povolíte ověřování a autorizaci jedním z těchto poskytovatelů, je k dispozici koncový bod přihlášení pro ověřování uživatelů a ověření tokenů ověřování od poskytovatele.When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. Uživatelům můžete snadno poskytnout libovolný počet možností přihlašování.You can provide your users with any number of these sign-in options with ease.

Starší cesta rozšíření existuje pro integraci s jinými zprostředkovateli identity nebo vlastním ověřovacím řešením, ale nedoporučuje se to.A legacy extensibility path exists for integrating with other identity providers or a custom auth solution, but this is not recommended. Místo toho zvažte použití podpory OpenID Connect.Instead, consider using the OpenID Connect support.

Tok ověřováníAuthentication flow

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 pro poskytovatele:The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider's SDK:

  • Bez sady Provider SDK: aplikace deleguje federované přihlašování k App Service.Without provider SDK: The application delegates federated sign-in to App Service. Většinou se jedná o prohlížeč pro aplikace v prohlížeči, který může uživateli prezentovat přihlašovací stránku poskytovatele.This is typically the case with browser apps, which can present the provider's login page to the user. Serverový kód spravuje proces přihlášení, takže se také nazývá tok směrovaného serveru nebo tok serveru.The server code manages the sign-in process, so it is also called server-directed flow or server flow. Tento případ se vztahuje na aplikace prohlížeče.This case applies to browser apps. Vztahuje se také na nativní aplikace, které uživatele podepisují pomocí Mobile Apps klientské sady SDK, protože sada SDK otevírá webové zobrazení k podepisování uživatelů pomocí ověřování App Service.It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication.
  • Se sadou SDK pro poskytovatele: aplikace podepisuje uživatele do poskytovatele ručně a pak odešle ověřovací token, aby App Service k ověření.With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. Většinou se jedná o aplikace bez prohlížeče, které nemůžou uživateli prezentovat přihlašovací stránku poskytovatele.This is typically the case with browser-less apps, which can't present the provider's sign-in page to the user. Kód aplikace spravuje proces přihlášení, takže se také nazývá tok směrovaného klientem nebo tok klienta.The application code manages the sign-in process, so it is also called client-directed flow or client flow. Tento případ se vztahuje na klienty rozhraní REST API, Azure Functionsa JavaScript, jakož i aplikace v prohlížeči, které v procesu přihlašování vyžadují větší flexibilitu.This case applies to REST APIs, Azure Functions, and JavaScript browser clients, as well as browser apps that need more flexibility in the sign-in process. Vztahuje se také na nativní mobilní aplikace, které uživatele podepisují pomocí sady SDK poskytovatele.It also applies to native mobile apps that sign users in using the provider's SDK.

Poznámka

Volání z důvěryhodné aplikace prohlížeče v App Service do jiného REST API v App Service nebo Azure Functions lze ověřit pomocí toku směrovaného na server.Calls from a trusted browser app in App Service to another REST API in App Service or Azure Functions can be authenticated using the server-directed flow. Další informace najdete v tématu Přizpůsobení ověřování a autorizace v App Service.For more information, see Customize authentication and authorization in App Service.

V následující tabulce jsou uvedené kroky toku ověřování.The table below shows the steps of the authentication flow.

KrokStep Bez sady Provider SDKWithout provider SDK Se sadou SDK pro poskytovateleWith provider SDK
1. podepsat uživatele1. Sign user in Přesměrovává klienta na /.auth/login/<provider> .Redirects client to /.auth/login/<provider>. Kód klienta podepisuje uživatele přímo se sadou SDK pro poskytovatele a přijímá ověřovací token.Client code signs user in directly with provider's SDK and receives an authentication token. Informace najdete v dokumentaci k poskytovateli.For information, see the provider's documentation.
2. po ověření2. Post-authentication Zprostředkovatel přesměrovává klienta na /.auth/login/<provider>/callback .Provider redirects client to /.auth/login/<provider>/callback. Token příspěvků klientských kódů od poskytovatele k /.auth/login/<provider> ověření.Client code posts token from provider to /.auth/login/<provider> for validation.
3. vytvoření ověřené relace3. Establish authenticated session App Service přidá ověřený soubor cookie pro odpověď.App Service adds authenticated cookie to response. App Service vrátí do klientského kódu svůj vlastní ověřovací token.App Service returns its own authentication token to client code.
4. zajišťovat ověřený obsah4. Serve authenticated content Klient zahrnuje ověřovací soubor cookie v následných požadavcích (automaticky zpracovávaných prohlížečem).Client includes authentication cookie in subsequent requests (automatically handled by browser). Klientský kód prezentuje ověřovací token v X-ZUMO-AUTH hlavičce (automaticky se zpracovává Mobile Apps klientské sady SDK).Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

Pro klientské prohlížeče App Service může automaticky směrovat všechny neověřené uživatele na /.auth/login/<provider> .For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. Můžete taky prezentovat uživatele s jedním nebo více /.auth/login/<provider> odkazy pro přihlášení k aplikaci pomocí poskytovatele podle vlastního výběru.You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

Chování autorizaceAuthorization behavior

V Azure Portalmůžete nakonfigurovat App Service autorizaci s řadou chování, když příchozí žádost není ověřena.In the Azure portal, you can configure App Service authorization with a number of behaviors when incoming request is not authenticated.

Snímek obrazovky s rozevíracím seznamem "akce, která se má provést, když se žádost neověřuje"

Tyto možnosti jsou popsány v následujících nadpisech.The following headings describe the options.

Povolení anonymních požadavků (žádná akce)Allow Anonymous requests (no action)

Tato možnost odloží autorizaci neověřeného provozu do kódu aplikace.This option defers authorization of unauthenticated traffic to your application code. U ověřených požadavků App Service také společně s ověřovacími informacemi v hlavičkách protokolu HTTP.For authenticated requests, App Service also passes along authentication information in the HTTP headers.

Tato možnost nabízí větší flexibilitu při zpracování anonymních požadavků.This option provides more flexibility in handling anonymous requests. Například umožňuje uživatelům prezentovat více poskytovatelů přihlášení .For example, it lets you present multiple sign-in providers to your users. Je však nutné napsat kód.However, you must write code.

Povolení pouze ověřených požadavkůAllow only authenticated requests

Možnost se **přihlásí pomocí <provider> **.The option is Log in with <provider>. App Service přesměruje všechny anonymní požadavky na /.auth/login/<provider> poskytovatele, kterého zvolíte.App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. Pokud anonymní požadavek pochází z nativní mobilní aplikace, vrácená odpověď je HTTP 401 Unauthorized .If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.

Pomocí této možnosti nemusíte v aplikaci psát žádný ověřovací kód.With this option, you don't need to write any authentication code in your app. Přesnější autorizaci, například autorizaci specifickou pro role, je možné zpracovat kontrolou deklarací identity uživatele (viz přístup k deklaracím uživatelů).Finer authorization, such as role-specific authorization, can be handled by inspecting the user's claims (see Access user claims).

Upozornění

Omezení přístupu tímto způsobem se vztahuje na všechna volání aplikace, která nemusí být žádoucí pro aplikace, které mají veřejně dostupnou domovskou stránku, stejně jako v mnoha aplikacích s jednou stránkou.Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.

Další zdroje informacíMore resources

Návody pro konkrétního poskytovatele:Provider-specific how-to guides: