Ověřování a autorizace v Azure Container Apps

Azure Container Apps poskytuje integrované funkce ověřování a autorizace (někdy označované jako Snadné ověřování), které zajišťují zabezpečení externí aplikace kontejneru s povoleným příchozím přenosem dat s minimálním nebo žádným kódem.

Podrobnosti o ověřování a autorizaci najdete v následujících příručkách pro váš výběr poskytovatele.

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. 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) ale 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 Container Apps šetří čas a úsilí tím, že poskytuje předem připravená ověřování s federovanými zprostředkovateli identit. Tyto funkce umožňují soustředit se na vývoj aplikace více času a méně času na sestavování systémů zabezpečení.

Nabízí například tyto výhody:

Azure Container Apps poskytuje přístup k různým integrovaným poskytovatelům ověřování.
Integrované funkce ověřování nevyžadují žádný konkrétní jazyk, sadu SDK, znalosti zabezpečení ani žádný kód, který musíte napsat.
Můžete se integrovat s několika poskytovateli, včetně Microsoft Entra ID, Facebooku, Googlu a X.

Poznámka:

Azure Container Apps používá stejný systém ověřování a autorizace jako Azure App Service. Další informace o ověřování a autorizaci najdete v tématu Ověřování a autorizace ve službě Azure App Service a Azure Functions.

Existují určité rozdíly v tom, jak Azure Container Apps implementuje autorizaci a ověřování mezi App Service. Obsah v tomto článku podrobně popisuje důležité rozdíly.

Poskytovatelé identity

Container Apps používá federovanou identitu, při níž poskytovatel identity třetí strany za vás spravuje identity uživatelů a proces ověřování. Ve výchozím nastavení jsou k dispozici následující zprostředkovatelé identity:

Poskytovatel	Koncový bod přihlášení	Praktické pokyny
Microsoft Identity Platform	`/.auth/login/aad`	Microsoft Identity Platform
Facebook	`/.auth/login/facebook`	Facebook
GitHub	`/.auth/login/github`	GitHub
Google	`/.auth/login/google`	Google
X	`/.auth/login/x`	X
Libovolný zprostředkovatel OpenID Connect	`/.auth/login/<providerName>`	OpenID Connect

Pokud používáte některého z těchto poskytovatelů, je koncový bod přihlášení k dispozici pro ověření uživatele a ověření ověřovacího tokenu od zprostředkovatele. Uživatelům můžete poskytnout libovolný počet těchto možností poskytovatele.

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

Tato funkce by se měla používat jenom s HTTPS. Ujistěte se, že allowInsecure je v konfiguraci ingressu vaší kontejnerové aplikace zakázané.

Aplikaci kontejneru můžete nakonfigurovat pro ověřování pomocí obsahu a rozhraní API webu nebo bez omezení přístupu k obsahu a rozhraním API webu. Pokud chcete omezit přístup aplikace jenom na ověřené uživatele, nastavte jeho nastavení Omezit přístup na Vyžadovat ověřování. Pokud se chcete ověřit, ale neomezovat přístup, nastavte jeho nastavení Omezit přístup na Možnost Povolit neověřený přístup.

Ve výchozím nastavení každá aplikace kontejneru vydává vlastní jedinečný soubor cookie nebo token pro ověřování. Můžete také zadat vlastní podpisové a šifrovací klíče.

Architektura funkcí

Komponenta middlewaru pro ověřování a autorizaci je součástí platformy, která běží jako kontejner sidecar na každé replice vaší aplikace. Pokud je tato možnost povolená, vaše aplikace zpracuje každý příchozí požadavek HTTP po průchodu vrstvou zabezpečení.

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

Ověřuje uživatele a klienty prostřednictvím zadaných zprostředkovatelů identity.
Spravuje autentizovanou relaci.
Vloží informace o identitě do hlaviček požadavků HTTP.

Modul ověřování a autorizace se spouští v samostatném kontejneru, který je izolovaný od kódu vaší aplikace. Vzhledem k tomu, že kontejner zabezpečení 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 poskytují v hlavičce požadavků, jak je vysvětleno v tomto článku.

Tok autentizace

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 SDK poskytovatele (tok řízený serverem nebo serverový tok): Aplikace deleguje federované přihlašování na Container Apps. Delegování se obvykle používá u aplikací prohlížeče, které uživateli zobrazí přihlašovací stránku poskytovatele.
Pomocí sady SDK poskytovatele (tok řízený klientem nebo tok klienta): Aplikace uživatele ručně přihlásí u poskytovatele a poté odešle autentizační token službě Container Apps k ověření. Tento přístup je typický pro aplikace bez prohlížeče, které uživateli nenabídnou přihlašovací stránku poskytovatele. Příkladem je nativní mobilní aplikace, která uživatele podepisuje pomocí sady SDK poskytovatele.

Volání z důvěryhodné aplikace prohlížeče v Container Apps do jiného rozhraní REST API v Container Apps 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í.

V tabulce jsou uvedené kroky toku ověřování.

Krok	Bez SDK poskytovatele	S využitím sady SDK poskytovatele
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 autentizaci	Zprostředkovatel přesměruje klienta na `/.auth/login/<PROVIDER>/callback`.	Klientský kód odesílá token od poskytovatele do `/.auth/login/<PROVIDER>` k ověření.
3. Navázat autentizovanou relaci	Container Apps přidá do odpovědi ověřený soubor cookie.	Container Apps vrací 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 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 Container Apps 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í při autorizaci

Na webu Azure Portal můžete upravit nastavení ověřování aplikace kontejneru a nakonfigurovat ho s různými chováními v případě, že příchozí požadavek není ověřený. Následující nadpisy popisují možnosti.

Povolit neověřený přístup: Tato možnost znemožní autorizaci neověřeného provozu do kódu aplikace. U ověřených požadavků služba Container Apps předává také ověřovací informace v hlavičce HTTP. Aplikace může k rozhodování o autorizaci žádosti použít informace v hlavičce.

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. Toto odmítnutí může být přesměrováním na některého 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 jako HTTP 401 Unauthorized nebo HTTP 403 Forbidden pro všechny požadavky.

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 k aplikaci platí pro všechny požadavky na vaši aplikaci. Tato omezení nemusí být vhodnější pro aplikace s veřejně dostupnou webovou stránkou, jak je typické u mnoha jednostrákových aplikací.

Poznámka:

Ve výchozím nastavení může každý uživatel ve vašem tenantovi Microsoft Entra požádat o token pro vaši aplikaci z ID Microsoft Entra. Aplikaci můžete nakonfigurovat v Microsoft Entra ID, pokud chcete omezit přístup k aplikaci na definovanou sadu uživatelů.

Ověřování ve službě Container Apps poskytuje integrované koncové body pro přihlášení a odhlášení. Když je tato funkce povolená, jsou tyto koncové body ve vaší kontejnerové aplikaci dostupné pod předponou trasy /.auth.

Konfigurace portálu nenabízí způsob, jak uživatelům prezentovat více poskytovatelů přihlašování (například Facebook i X). Není ale obtížné do aplikace přidat funkce. Postup je uveden níže:

Nejprve na stránce Ověřování nebo autorizace na webu Azure Portal nakonfigurujte každého zprostředkovatele identity, kterého chcete povolit.

V akci, která se má provést, když požadavek není ověřený, vyberte Povolit anonymní žádosti (bez akce).

Na přihlašovací stránce nebo na navigačním panelu nebo v jiném umístění vaší aplikace přidejte odkaz pro přihlášení ke každému poskytovateli, který jste povolili (/.auth/login/<provider>). Příklad:

<a href="/.auth/login/aad">Log in with the Microsoft Identity Platform</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/x">Log in with X</a>

Když uživatel vybere některý z odkazů, uživatelské rozhraní pro příslušné zprostředkovatele se uživateli zobrazí.

Upozornění

U klientských aplikací může správce směrování na straně klienta zachytit trasy /.auth/login/, čímž zabrání tomu, aby sidecar pro ověřování přijímal požadavky. Ujistěte se, že konfigurace směrování na straně klienta umožňuje serveru zpracovávat tyto trasy.

Chcete-li po přihlášení uživatele přesměrovat na vlastní adresu URL, použijte parametr řetězce dotazu post_login_redirect_uri (nezaměňujte jej s identifikátorem Redirect URI v konfiguraci zprostředkovatele identity). Chcete-li například po přihlášení přesměrovat uživatele na /Home/Index, použijte následující kód HTML:

<a href="/.auth/login/<provider>?post_login_redirect_uri=/Home/Index">Log in</a>

V přihlášení řízeném klientem se aplikace přihlásí uživatele k zprostředkovateli identity pomocí sady SDK specifické pro zprostředkovatele. Kód aplikace pak odešle výsledný ověřovací token do Container Apps k ověření (viz ověřovací tok) pomocí požadavku HTTP POST.

Pokud chcete ověřit token zprostředkovatele, musí být aplikace kontejneru nejprve nakonfigurovaná s požadovaným poskytovatelem. Za běhu aplikace po získání autentizačního tokenu od poskytovatele odešlete token do /.auth/login/<provider> k ověření. Příklad:

POST https://<hostname>.azurecontainerapps.io/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Formát tokenu se mírně liší podle poskytovatele. Podrobnosti najdete v následující tabulce:

Hodnota zprostředkovatele	Požadováno v textu požadavku	Komentáře
`aad`	`{"access_token":"<ACCESS_TOKEN>"}`	Vlastnosti `id_token`a `refresh_token` , `expires_in`jsou volitelné.
`microsoftaccount`	`{"access_token":"<ACCESS_TOKEN>"}` nebo `{"authentication_token": "<TOKEN>"`	`authentication_token` je upřednostňovaná před `access_token`. Vlastnost `expires_in` je nepovinná. Při vyžadování tokenu ze služeb Live vždy požadujte rozsah `wl.basic`.
`google`	`{"id_token":"<ID_TOKEN>"}`	Vlastnost `authorization_code` je nepovinná. Poskytnutí hodnoty `authorization_code` přidá do úložiště tokenů přístupový token a obnovovací token. Je-li zadáno `authorization_code`, může být také volitelně doplněno vlastností `redirect_uri`.
`facebook`	`{"access_token":"<USER_ACCESS_TOKEN>"}`	Použijte platný přístupový token uživatele z Facebooku.
`twitter`	`{"access_token":"<ACCESS_TOKEN>", "access_token_secret":"<ACCESS_TOKEN_SECRET>"}`

Pokud je token poskytovatele úspěšně ověřen, rozhraní API vrátí v těle odpovědi authenticationToken, což je váš token relace.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Jakmile budete mít tento token relace, můžete přistupovat k chráněným prostředkům aplikace přidáním hlavičky X-ZUMO-AUTH do svých požadavků HTTP. Příklad:

GET https://<hostname>.azurecontainerapps.io/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Odhlášení z relace

Uživatelé se můžou odhlásit odesláním GET požadavku do koncového /.auth/logout bodu aplikace. Žádost GET provádí následující akce:

Vymaže ověřovací soubory cookie z aktuální relace.
Odstraní tokeny aktuálního uživatele z úložiště tokenů.
Provede odhlášení na straně serveru u poskytovatele identity pro Microsoft Entra ID a Google.

Tady je jednoduchý odkaz pro odhlášení na webové stránce:

<a href="/.auth/logout">Sign out</a>

Ve výchozím nastavení úspěšné odhlášení přesměruje klienta na adresu URL /.auth/logout/done. Stránku přesměrování po odhlášení můžete změnit přidáním parametru post_logout_redirect_uri dotazu. Příklad:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Nezapomeňte zakódovat hodnotu post_logout_redirect_uri.

Adresa URL musí být hostovaná ve stejné doméně při použití plně kvalifikovaných adres URL.

Přístup k deklaracím identity uživatelů v kódu aplikace

Pro všechny jazykové frameworky služba Container Apps zpřístupňuje claimy z příchozího tokenu vašemu aplikačnímu kódu. Claimy se vkládají do hlaviček požadavku a jsou přítomné bez ohledu na to, zda pocházejí od ověřeného koncového uživatele nebo klientské aplikace. Externí požadavky nesmějí tyto hlavičky nastavovat, takže jsou přítomny pouze tehdy, pokud je nastaví Container Apps. Mezi příklady hlaviček patří:

X-MS-CLIENT-PRINCIPAL-NAME
X-MS-CLIENT-PRINCIPAL-ID

Kód napsaný v libovolném jazyce nebo rozhraní může získat informace, které potřebuje, z těchto hlaviček.

Kromě těchto hlaviček identit může vaše aplikace přistupovat k ověřovacím tokenům (například Microsoft Entra přístupových tokenů) prostřednictvím hlaviček požadavků, jako je X-MS-TOKEN-AAD-ACCESS-TOKEN. Pokud chcete tyto tokeny zpřístupnit, musíte úložiště tokenů povolit jako součást nastavení ověřování vaší aplikace kontejneru. Po povolení zahrnují požadavky odeslané do vaší aplikace další hlavičky související s tokeny v závislosti na nakonfigurovaného zprostředkovatele identity a toku ověřování.

Poznámka:

Různá jazyková rozhraní mohou tyto hlavičky prezentovat kódu aplikace v různých formátech, jako jsou malá písmena nebo velká písmena názvu.

Zabezpečení koncových bodů pomocí EasyAuth

Při zabezpečení koncových bodů pomocí ověřování Azure Container Apps musíte zaregistrovat aplikaci s ID Microsoft Entra a nakonfigurovat nastavení ověřování.

Pokud chcete nastavit zabezpečený přístup, postupujte takto:

Vytvoření registrace aplikace Azure AD

az ad app create \
  --display-name <APP_DISPLAY_NAME> \
  --sign-in-audience AzureADMyOrg
---

Povolte aplikaci vydávání tokenů ID. Tento krok je nutný pro podporu snadného ověřování.
```
az ad app update \
  --id <APPLICATION_ID> \
  --enable-id-token-issuance true
```

Přidejte identifikátor URI přesměrování pro zpětné volání Easy Auth.

az ad app update \
  --id <APP_ID> \
  --web-redirect-uris "https://<APP-NAME>.<ENVIRONMENT-NAME>.<REGION>.azurecontainerapps.io/.auth/login/aad/callback"
---

Vygenerování tajného klíče klienta

az ad app credential reset \
  --id <APP_ID>" \
  --display-name "<APP_NAME>-Secret"
---

Vytvořte principál služby pro vaši aplikaci.
```
az ad sp create --id <APP_ID>
---
```
Nakonfigurujte aplikaci kontejneru tak, aby používala ověřování Microsoft Entra ID.

Ujistěte se, že hodnota, kterou zadáte pro <APP_NAME> zástupný symbol, je název aplikace, kterou jste nakonfigurovali pro práci s EasyAuth.
```
az containerapp auth microsoft update \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --client-id <APP_ID> \
  --client-secret <CLIENT_SECRET> \
  --tenant-id <TENANT_ID> \
  --yes
```

Další kroky

Podrobnosti o zabezpečení kontejnerové aplikace najdete v následujících článcích.

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-07-08