Sdílet prostřednictvím

Konfigurace aplikace App Service nebo Azure Functions tak, aby používala přihlášení Microsoft Entra

Vyberte jiného poskytovatele ověřování a přejděte k němu.

V tomto článku se dozvíte, jak nakonfigurovat ověřování pro Azure App Service nebo Azure Functions tak, aby se vaše aplikace přihlašuje uživatele pomocí Microsoft Identity Platform (Microsoft Entra) jako zprostředkovatele ověřování.

Volba tenanta pro vaši aplikaci a její uživatele

Než vaše aplikace může přihlašovat uživatele, musíte ji zaregistrovat u pracovního nájemce nebo externího nájemce. Pokud aplikaci zpřístupňujete zaměstnancům nebo obchodním hostům, zaregistrujte ji ve firemním tenantu. Pokud je vaše aplikace určená pro spotřebitele a firemní zákazníky, zaregistrujte ji v externím tenantovi.

  1. Přihlaste se do Azure portálu a přejděte k vaší aplikaci.

  2. V nabídce vlevo v aplikaci vyberte Nastavení>ověřování a pak vyberte Přidat zprostředkovatele identity.

  3. Na stránce Přidat zprostředkovatele identity vyberte Microsoft jako hodnotu zprostředkovatele identity pro přihlášení k Microsoftu a identitám Microsoft Entra.

  4. V části Zvolte tenanta pro vaši aplikaci a její uživatele vyberte jednu z těchto akcí:

    • Konfigurace pracovních sil (aktuální tenant) pro zaměstnance a obchodní hosty
    • Externí konfigurace pro uživatele a firemní zákazníky

Volba registrace aplikace

Funkce ověřování služby App Service pro vás může automaticky vytvořit registraci aplikace. Nebo můžete použít registraci, kterou vy nebo správce adresáře vytváříte samostatně.

Pokud nepotřebujete vytvořit registraci aplikace samostatně, vytvořte automaticky novou registraci aplikace. Registraci aplikace můžete později upravit v Centru pro správu Microsoft Entra , pokud chcete.

Nejběžnějšími případy použití stávající registrace aplikace jsou následující situace:

  • Váš účet nemá oprávnění k vytváření registrací aplikací ve vašem tenantovi Microsoft Entra.
  • Chcete použít registraci aplikace z jiného tenanta Microsoft Entra, než je ten, který obsahuje vaši aplikaci. To je vždy případ, pokud jste při výběru tenanta vybrali externí konfiguraci .
  • Možnost vytvoření nové registrace není dostupná pro cloudy státní správy.

Možnost 1: Vytvoření a použití nové registrace aplikace

  1. Vyberte Vytvořit novou registraci aplikace.

  2. Jako Název zadejte název nové registrace aplikace.

  3. Vyberte hodnotu podporovaného typu účtu :

    • Aktuální tenant – jediný nájemce Účty pouze v tomto organizačním adresáři. Všechny účty uživatelů a hostů ve vašem adresáři můžou používat vaši aplikaci nebo rozhraní API. Tuto možnost použijte, pokud je cílová cílová skupina interní pro vaši organizaci.
    • Libovolný adresář Microsoft Entra – Víceklientový. Účty v libovolném adresáři organizace. Vaši aplikaci nebo rozhraní API můžou používat všichni uživatelé s pracovním nebo školním účtem od Microsoftu. Mezi tyto účty patří školy a firmy, které používají Office 365. Tuto možnost použijte, pokud je cílová skupina firemní nebo vzdělávací zákazníky a chcete povolit víceklientské prostředí.
    • Jakýkoli adresář Microsoft Entra a osobní účty Microsoft. Účty v libovolném organizačním adresáři a osobních účtech Microsoft (například Skype nebo Xbox). Vaši aplikaci nebo rozhraní API můžou používat všichni uživatelé s pracovním nebo školním účtem nebo osobním účtem Microsoft. Zahrnuje školy a firmy, které používají Office 365, spolu s osobními účty, které se používají k přihlášení ke službám, jako je Xbox a Skype. Pomocí této možnosti můžete cílit na nejširší sadu identit Microsoftu a povolit víceklientské prostředí.
    • Pouze osobní účty Microsoft. Osobní účty, které se používají k přihlášení ke službám, jako je Xbox a Skype. Pomocí této možnosti můžete cílit na nejširší sadu identit Microsoftu.

Pokud chcete, můžete později změnit název registrace nebo podporované typy účtů.

Tajný klíč klienta se vytvoří jako nastavení aplikace typu slot-sticky s názvem MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Pokud chcete tajný kód spravovat ve službě Azure Key Vault, můžete toto nastavení později aktualizovat tak, aby používalo odkazy na službu Key Vault. Případně můžete tuto možnost změnit tak, aby používala identitu místo tajného klíče klienta. Podpora použití identity je aktuálně ve verzi Preview.

Možnost 2: Použití existující registrace vytvořené samostatně

Pokud chcete použít existující registraci, vyberte jednu z těchto akcí:

  • Vyberte existující registraci aplikace v tomto adresáři. Pak v rozevíracím seznamu vyberte registraci aplikace.

  • Zadejte podrobnosti o stávající registraci aplikace. Pak zadejte:

    • ID aplikace (klienta).

    • Tajný klíč klienta (doporučeno) Hodnota tajného kódu, kterou aplikace používá k prokázání své identity při žádosti o token. Tato hodnota se uloží do konfigurace vaší aplikace jako nastavení aplikace s názvem MICROSOFT_PROVIDER_AUTHENTICATION_SECRET slot-sticky. Pokud tajný klíč klienta není nastavený, přihlašovací operace ze služby používají implicitní tok udělení OAuth 2.0, který nedoporučujeme .

      Aplikaci můžete také nakonfigurovat tak, aby používala identitu místo tajného klíče klienta. Podpora použití identity je aktuálně ve verzi Preview.

    • Adresa URL vystavitele Tato adresa URL má tvar <authentication-endpoint>/<tenant-id>/v2.0. Nahraďte <authentication-endpoint> hodnotou koncového bodu ověřování specifickou pro cloudové prostředí. Tenant pracovních sil v globálním Azure by například používal https://sts.windows.net jako svůj koncový bod ověřování.

Pokud potřebujete ručně vytvořit registraci aplikace v pracovním tenantovi, viz Registrace aplikace na platformě Microsoft Identity Platform. Při procházení procesu registrace nezapomeňte poznamenat ID aplikace (klienta) a hodnoty tajných kódů klienta.

Během procesu registrace v části Identifikátory URI přesměrování vyberte Web pro platformu a zadejte identifikátor URI přesměrování. Například zadejte https://contoso.azurewebsites.net/.auth/login/aad/callback.

Teď upravte registraci aplikace:

  1. V levém podokně vyberte Zveřejnit rozhraní API>Přidat>uložit. Tato hodnota jednoznačně identifikuje aplikaci, když se používá jako prostředek, což umožňuje, aby byly požadovány tokeny, které udělují přístup. Hodnota je předpona pro obory, které vytvoříte.

    Pro aplikaci s jedním tenantem můžete použít výchozí hodnotu, která je ve formuláři api://<application-client-id>. Můžete také zadat čitelnější identifikátor URI, například https://contoso.com/apina základě jedné z ověřených domén pro vašeho tenanta. U víceklientských aplikací musíte zadat vlastní identifikátor URI. Další informace o přijatých formátech identifikátorů URI ID aplikace naleznete v tématu Osvědčené postupy zabezpečení pro vlastnosti aplikace v Microsoft Entra ID.

  2. Vyberte Přidat obor a pak:

    1. Do pole Název oboru zadejte user_impersonation.
    2. Pokud chcete uživatelům povolit souhlas s tímto oborem, vyberte v okně Kdo může souhlasit.
    3. Zadejte název oboru souhlasu. Zadejte popis, který mají uživatelé zobrazit na stránce souhlasu. Například zadejte Accessnázev aplikace.
    4. Vyberte Přidat rozsah.

  3. (Doporučeno) Vytvořte klientské prohlášení pro aplikaci Vytvoření tajného klíče klienta:

    1. V levém podokně vyberte Certifikáty a tajné klíče>Tajné klíče klienta>Nové tajné klíče klienta.
    2. Zadejte popis a vypršení platnosti a pak vyberte Přidat.
    3. V poli Hodnota zkopírujte hodnotu tajného klíče klienta. Po přesunutí mimo tuto stránku se tato stránka znovu nezobrazí.

    Aplikaci můžete také nakonfigurovat tak, aby používala identitu místo tajného klíče klienta. Podpora použití identity je aktuálně ve verzi Preview.

  4. (Volitelné) Pokud chcete přidat více adres URL odpovědí, vyberte Ověřování.

Konfigurace dalších kontrol

Další kontroly určují, které požadavky mají povolený přístup k vaší aplikaci. Toto chování můžete nyní přizpůsobit nebo můžete tato nastavení upravit později z hlavní stránky Ověřování výběrem možnosti Upravit vedle nastavení ověřování.

V případě požadavku klientské aplikace zvolte, jestli chcete:

  • Povolit žádosti pouze z této aplikace samotné.
  • Povolte požadavky z konkrétních klientských aplikací.
  • Povolte žádosti z jakékoli aplikace (nedoporučuje se).

V případě požadavku na identitu zvolte, jestli chcete:

  • Povolte požadavky z jakékoli identity.
  • Povolte požadavky z konkrétních identit.

V případě požadavku nájemníka vyberte možnost:

  • Povolte žádosti pouze od vystavujícího nájemce.
  • Povolte žádosti od konkrétních tenantů.
  • Použijte výchozí omezení podle vystavitele.

Vaše aplikace může stále potřebovat provádět další rozhodnutí o autorizaci v kódu. Další informace najdete v tématu Použití předdefinovaných zásad autorizace dále v tomto článku.

Konfigurace nastavení ověřování

Nastavení ověřování určují, jak vaše aplikace reaguje na neověřené požadavky. Výchozí výběry přesměrují všechny požadavky na přihlášení pomocí tohoto nového poskytovatele. Toto chování můžete nyní přizpůsobit nebo můžete tato nastavení upravit později z hlavní stránky Ověřování výběrem možnosti Upravit vedle nastavení ověřování. Další informace najdete v tématu Průběh autentizace.

Pokud chcete omezit přístup, rozhodněte se, jestli chcete:

  • Vyžadovat ověření.
  • Povolte neověřený přístup.

V případě neověřených požadavků zvolte možnosti chyb:

  • HTTP 302 Found redirect: doporučeno pro weby
  • HTTP 401 Unauthorized: Doporučeno pro rozhraní API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

Vyberte úložiště tokenů (doporučeno). Úložiště tokenů shromažďuje, ukládá a aktualizuje tokeny pro vaši aplikaci. Toto chování můžete později zakázat, pokud vaše aplikace nepotřebuje tokeny nebo pokud potřebujete optimalizovat výkon.

Přidejte zprostředkovatele identity

Pokud jste vybrali konfiguraci pracovních sil, můžete vybrat Další: Oprávnění a přidat všechna oprávnění Microsoft Graphu, která aplikace potřebuje. Tato oprávnění se přidají do registrace aplikace, ale můžete je také později změnit. Pokud jste vybrali externí konfiguraci, můžete později přidat oprávnění Microsoft Graphu.

  • Vyberte Přidat.

Teď jste připraveni k ověřování ve vaší aplikaci použít platformu Microsoft Identity Platform. Zprostředkovatel je uvedený na stránce Ověřování . Odtud můžete tuto konfiguraci poskytovatele upravit nebo odstranit.

Příklad konfigurace přihlášení Microsoft Entra pro webovou aplikaci, která přistupuje ke službě Azure Storage a Microsoft Graphu, najdete v tématu Přidání ověřování aplikací do webové aplikace.

Autorizace žádostí

App Service zpracovává pouze ověřování ve výchozím nastavení. Určuje, jestli je volající ten, kdo říká, že je. Autorizace, která určuje, jestli má volající mít přístup k určitému prostředku, je krokem nad rámec ověřování. Další informace najdete v tématu Základy autorizace.

Vaše aplikace může rozhodovat o autorizaci v kódu. Ověřování ve službě App Service poskytuje některé integrované kontroly, které vám můžou pomoct, ale samotné nemusí stačit k pokrytí potřeb autorizace vaší aplikace. Tyto funkce jsou popsány v následujících částech.

Návod

Víceklientní aplikace by měly v rámci tohoto procesu ověřit vystavitele a ID tenanta požadavku, aby se zajistilo, že jsou hodnoty povolené. Pokud je ověřování služby App Service nakonfigurované pro scénář s více tenanty, neověřuje, ze kterého tenanta žádost pochází. Aplikace může být potřeba omezit na konkrétní tenanty na základě toho, jestli se organizace zaregistrovala ke službě (například). Podívejte se na aktualizujte svůj kód pro zpracování více hodnot vydavatelů.

Provádění ověření z kódu aplikace

Při autorizačních kontrolách v kódu aplikace můžete použít informace o nárocích, které zpřístupňuje autentizace App Service. Další informace najdete v tématu Přístup k deklaracím identity uživatelů v kódu aplikace.

Vložená x-ms-client-principal hlavička obsahuje objekt JSON kódovaný kódem Base64 s deklaracemi, které jsou uplatněny na volajícího. Ve výchozím nastavení tyto deklarace procházejí mapováním, takže názvy nemusí vždy odpovídat tomu, co se v tokenu zobrazí. Nárok je například tid namapován na http://schemas.microsoft.com/identity/claims/tenantid místo něj.

Můžete také pracovat přímo s podkladovým přístupovým tokenem z vložené x-ms-token-aad-access-token hlavičky.

Použití předdefinovaných zásad autorizace

Vytvořená registrace aplikace ověřuje příchozí požadavky pro vašeho tenanta Microsoft Entra. Ve výchozím nastavení také umožňuje přístup k aplikaci komukoli v rámci tenanta. Tento přístup je v pořádku pro mnoho aplikací. Některé aplikace musí dále omezit přístup tím, že se rozhoduje o autorizaci.

Váš kód aplikace je často nejlepším místem pro zpracování vlastní logiky autorizace. V případě běžných scénářů ale platforma Microsoft Identity Platform poskytuje integrované kontroly, které můžete použít k omezení přístupu.

Tato část ukazuje, jak povolit integrované kontroly pomocí rozhraní API ověřování služby App Service V2. Jediným způsobem konfigurace těchto předdefinovaných kontrol je v současné době použití šablon Azure Resource Manageru nebo rozhraní REST API.

V rámci objektu rozhraní API má validation konfigurace zprostředkovatele identity Microsoft Entra oddíl, který může zahrnovat defaultAuthorizationPolicy objekt, jak je znázorněno v následující struktuře:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Vlastnictví Popis
defaultAuthorizationPolicy Skupina požadavků, které musí být splněny pro přístup k aplikaci. Přístup se uděluje na základě logického AND na každou z nakonfigurovaných vlastností. Pokud jsou obě allowedApplications a allowedPrincipals nakonfigurovány, musí příchozí žádost splňovat oba požadavky, aby byla přijata.
allowedApplications Seznam povolených ID klienta řetězcové aplikace, které představují prostředek klienta, který volá do aplikace. Pokud je tato vlastnost nakonfigurována jako neprázdné pole, jsou přijímány pouze tokeny získané aplikací zadanou v seznamu.

Tato zásada vyhodnocuje appid nebo azp u příchozího tokenu, který musí být přístupovým tokenem. Viz nároky na datovou část.
allowedPrincipals Skupina kontrol, které určují, zda uživatel, kterého příchozí požadavek zastupuje, má přístup k aplikaci. Logika spokojenosti allowedPrincipals je založena na OR základě nakonfigurovaných vlastností.
identities (v části allowedPrincipals) Seznam povolených ID objektů řetězců, které představují uživatele nebo aplikace s přístupem. Pokud je tato vlastnost nakonfigurována jako neprázdné pole, může být požadavek splněn, allowedPrincipals pokud je uživatel nebo aplikace, které požadavek představuje, zadán v seznamu. V seznamu identit je limit 500 znaků (celkem).

Tato zásada vyhodnocuje oid deklaraci příchozího tokenu. Viz nároky na datovou část.

Můžete také nakonfigurovat některé kontroly prostřednictvím nastavení aplikace bez ohledu na verzi rozhraní API, kterou používáte. Nastavení aplikace WEBSITE_AUTH_AAD_ALLOWED_TENANTS můžete nakonfigurovat seznamem až 10 ID tenantů, oddělených čárkami; například aaaabbbb-0000-cccc-1111-dddd2222eeee. Toto nastavení může vyžadovat, aby příchozí token pocházel od jednoho ze zadaných nájemců, jak je určeno nárokem tid.

Můžete nakonfigurovat WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL nastavení aplikace na true nebo 1, aby vyžadovalo, aby příchozí token zahrnoval oid deklaraci identity. Pokud jste nakonfigurovali allowedPrincipals.identities, toto nastavení se ignoruje a je považováno za pravdivé, protože nárok oid je kontrolován vůči tomuto poskytnutému seznamu identit.

Požadavky, které neprojdou těmito vestavěnými kontrolami, získají odpověď HTTP 403 Forbidden .

Použití spravované identity místo tajného kódu (Preview)

Místo konfigurace tajného klíče klienta pro registraci aplikace můžete nakonfigurovat aplikaci tak, aby důvěřovala spravované identitě (Preview). Použití identity místo tajného klíče znamená, že nemusíte spravovat tajný kód. Nemáte žádné události vypršení tajemství, které je potřeba zpracovat, a nemáte stejnou úroveň rizika spojeného s možným prozrazením nebo únikem tohoto tajemství.

Identita umožňuje vytvořit přihlašovací údaje federované identity, které je možné použít místo tajného klíče klienta jako kontrolní výraz klienta. Tento přístup je k dispozici pouze pro konfigurace pracovních sil. Integrovaná funkce ověřování aktuálně podporuje přihlašovací údaje federované identity ve verzi Preview.

Pomocí kroků v této části můžete nakonfigurovat prostředek služby App Service nebo Azure Functions tak, aby používal tento vzor. Zde uvedené kroky předpokládají, že jste už nastavili registraci aplikace pomocí jedné z podporovaných metod a že už máte definovaný tajný klíč.

  1. Podle těchto pokynů vytvořte prostředek identity spravované uživatelem.

  2. Přiřaďte tuto identitu k prostředku služby App Service nebo Azure Functions.

    Důležité

    Spravovaná identita přiřazená uživatelem, kterou vytvoříte, by se měla přiřazovat pouze k aplikaci App Service nebo Azure Functions prostřednictvím této registrace. Pokud přiřadíte tuto identitu jinému prostředku, dáváte tak tomuto prostředku zbytečný přístup k registraci vaší aplikace.

  3. Poznamenejte si ID objektu a hodnoty ID klienta spravované identity. Id objektu budete potřebovat k vytvoření přihlašovacích údajů federované identity v dalším kroku. ID klienta spravované identity použijete v pozdějším kroku.

  4. Postupujte podle pokynů k ID Microsoft Entra a nakonfigurujte přihlašovací údaje federované identity v existující aplikaci. Tyto pokyny obsahují také části pro aktualizaci kódu aplikace, které můžete přeskočit.

  5. Přidejte nové nastavení aplikace s názvem OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Nastavte jeho hodnotu na hodnotu ID klienta spravované identity, kterou jste získali v předchozím kroku. Nepoužívejte ID klienta registrace vaší aplikace. Nezapomeňte toto nastavení aplikace označit jako slot-sticky.

  6. V předdefinovaných nastaveních ověřování pro prostředek aplikace nastavte název nastavení klientského tajného klíče na OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Pokud chcete tuto změnu provést pomocí webu Azure Portal:

    1. Vraťte se k prostředku služby App Service nebo Azure Functions a vyberte kartu Ověřování .
    2. V části Zprostředkovatel identity pro položku Microsoft vyberte ikonu ve sloupci Upravit .
    3. V dialogovém okně Upravit zprostředkovatele identity otevřete rozevírací seznam pro název nastavení tajného klíče klienta a vyberte OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Vyberte Uložit.

    Pokud chcete tuto změnu provést pomocí rozhraní REST API:

    • Nastavte vlastnost clientSecretSettingName na OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Tuto vlastnost najdete v části propertiesazureActiveDirectory>registrationidentityProviders>>.

  7. Ověřte, že aplikace funguje podle očekávání. Měli byste být schopni úspěšně provést novou akci přihlášení.

Až budete spokojeni s chováním systému při použití spravované identity, odeberte existující tajný klíč.

  1. Ujistěte se, že váš kód aplikace nezávisí na nastavení aplikace. Pokud ano, aktualizujte kód aplikace podle pokynů a požádejte o přístupový token.

  2. Odeberte nastavení aplikace, které dříve drželo váš tajný klíč. Název tohoto nastavení aplikace je předchozí hodnota názvu nastavení tajného klíče klienta před nastavením na OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Přihlaste se do Centra pro správu Microsoft Entra pomocí tenanta, který obsahuje vaši registraci aplikace. Znovu přejděte na registraci aplikace.

  4. V části Certifikáty a tajné kódy vyberte Tajné kódy klienta a odeberte tajný klíč klienta.

Vaše aplikace je teď nakonfigurovaná tak, aby používala ověřování Microsoft Entra ID bez tajných kódů.

Konfigurace klientských aplikací pro přístup ke službě App Service

V předchozích částech jste zaregistrovali službu App Service nebo aplikaci Azure Functions k ověřování uživatelů. Následující části vysvětlují, jak zaregistrovat nativní klienty nebo aplikace na pozadí v Microsoft Entra. Tito klienti nebo aplikace můžou požádat o přístup k rozhraním API vystaveným službou App Service jménem uživatelů nebo samotných, například v N-úrovňové architektuře. Pokud chcete ověřovat jenom uživatele, postup v následujících částech se nevyžaduje.

Nativní klientská aplikace

Nativní klienty můžete zaregistrovat a požádat o přístup k rozhraním API vaší aplikace služby App Service jménem přihlášeného uživatele:

  1. V nabídce webu Azure Portal vyberte Microsoft Entra ID.

  2. V levém podokně vyberte Spravovat>registrace aplikací. Pak vyberte Nová registrace.

  3. V podokně Registrace aplikace zadejte název registrace aplikace.

  4. V Přesměrování URI vyberte veřejný klient/nativní (mobilní a desktopová aplikace) a zadejte adresu URL pro přesměrování. Například zadejte https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Vyberte Zaregistrovat.

  6. Po vytvoření registrace aplikace zkopírujte hodnotu ID aplikace (klienta).

    Poznámka:

    Pro aplikaci Microsoft Store použijte package SID jako identifikátor URI.

  7. V levém podokně vyberte Spravovat>oprávnění rozhraní API. Pak vyberte Přidat oprávnění>Moje rozhraní API.

  8. Vyberte registraci aplikace, kterou jste vytvořili dříve pro aplikaci App Service. Pokud registraci aplikace nevidíte, ujistěte se, že jste do registrace aplikace přidali oprávnění user_impersonation.

  9. V části Delegovaná oprávnění vyberte user_impersonation a pak vyberte Přidat oprávnění.

Právě jste nakonfigurovali nativní klientskou aplikaci, která může požádat o přístup k aplikaci App Service jménem uživatele.

Klientská aplikace démona (volání mezi službami)

V N-vrstvé architektuře může klientská aplikace získat token pro volání aplikace App Service nebo aplikace Azure Functions jménem samotné klientské aplikace, nikoli jménem uživatele. Tento scénář je užitečný pro neinteraktivní aplikace démona, které provádějí úlohy bez přihlášeného uživatele. Používá standardní udělení přihlašovacích údajů klienta OAuth 2.0. Další informace najdete v tématu Microsoft Identity Platform a tok přihlašovacích údajů klienta OAuth 2.0.

  1. V nabídce webu Azure Portal vyberte Microsoft Entra ID.

  2. V levém podokně vyberte Spravovat>registrace aplikací. Pak vyberte Nová registrace.

  3. V podokně Registrace aplikace zadejte název registrace aplikace.

  4. Pro aplikaci démona nepotřebujete identifikátor URI přesměrování, takže pole Identifikátor URI přesměrování můžete ponechat prázdné.

  5. Vyberte Zaregistrovat.

  6. Po vytvoření registrace aplikace zkopírujte hodnotu ID aplikace (klienta).

  7. V levém podokně vyberte Spravovat>certifikáty a tajné kódy. Pak vyberte Tajné kódy>klienta Nový tajný klíč klienta.

  8. Zadejte popis a vypršení platnosti a pak vyberte Přidat.

  9. V poli Hodnota zkopírujte hodnotu tajného klíče klienta. Po přesunutí mimo tuto stránku se tato stránka znovu nezobrazí.

Teď můžete požádat o přístupový token pomocí ID klienta a tajného klíče klienta. resource Nastavte parametr na hodnotu identifikátoru URI ID aplikace cílové aplikace. Výsledný přístupový token se pak dá cílové aplikaci předložit prostřednictvím standardní autorizační hlavičky OAuth 2.0. Ověřování služby App Service potvrdí a použije token k označení, že volající byl ověřen. V tomto případě je volající aplikací, nikoli uživatelem.

Tento přístup umožňuje libovolné klientské aplikaci ve vašem tenantovi Microsoft Entra požádat o přístupový token a ověřit ho v cílové aplikaci. Pokud chcete také vynutit autorizaci tak, aby umožňovala pouze určité klientské aplikace, musíte provést další konfiguraci.

  1. Definujte roli aplikace v manifestu registrace aplikace, která představuje aplikaci App Service nebo Azure Functions, kterou chcete chránit.

  2. V registraci aplikace, která představuje klienta, který je potřeba autorizovat, vyberte oprávnění rozhraní APIPřidat oprávnění>>Moje rozhraní API.

  3. Vyberte registraci aplikace, kterou jste vytvořili dříve. Pokud registraci aplikace nevidíte, ujistěte se, že jste přidali roli aplikace.

  4. V části Oprávnění aplikace vyberte dříve vytvořenou roli aplikace. Pak vyberte Přidat oprávnění.

  5. Vyberte Udělit souhlas správce, abyste autorizovali klientskou aplikaci k žádosti o oprávnění.

    Podobně jako v předchozím scénáři (před přidáním jakýchkoli rolí) teď můžete požádat o přístupový token pro stejný cílový prostředek. Přístupový token obsahuje roles deklaraci identity, která obsahuje role aplikace, které byly autorizované pro klientskou aplikaci.

V rámci cílové služby App Service nebo kódu aplikace Azure Functions teď můžete ověřit, že token má očekávané role. Ověřování služby App Service neprovádí toto ověření. Další informace najdete v tématu Přístup k deklaracím identity uživatelů v kódu aplikace.

Právě jste nyní nakonfigurovali klientskou aplikaci typu démon, která může přistupovat k aplikaci App Service pomocí vlastní identity.

Osvědčené postupy

Bez ohledu na konfiguraci, kterou používáte k nastavení ověřování, zajistí následující osvědčené postupy zabezpečení tenanta a aplikací:

  • Každou aplikaci App Service nakonfigurujte s vlastní registrací aplikace v Microsoft Entra.
  • Udělte každé aplikaci App Service vlastní oprávnění a souhlas.
  • Vyhněte se sdílení oprávnění mezi prostředími. Pro samostatné nasazovací sloty použijte samostatné registrace aplikací. Při testování nového kódu může tento postup pomoct zabránit problémům v ovlivnění produkční aplikace.

Migrace do Microsoft Graphu

Některé starší aplikace můžou být nastavené se závislostí na Azure AD Graphu, který je zastaralý a má být zcela vyřazen. Například kód vaší aplikace může využít Azure AD Graph ke kontrole členství ve skupině jako součást autorizačního filtru v procesu middlewaru. Aplikace by se měly přesunout do Microsoft Graphu. Další informace najdete v tématu Migrace aplikací z Azure AD Graphu do Microsoft Graphu.

Během této migrace možná budete muset provést určité změny konfigurace ověřování pomocí služby App Service. Po přidání oprávnění Microsoft Graphu k registraci aplikace můžete:

  • Aktualizujte hodnotu adresy URL vystavitele tak, aby obsahovala příponu /v2.0 , pokud ještě není.

  • Odeberte žádosti o oprávnění Azure AD Graphu z vaší konfigurace přihlašování. Vlastnosti, které se mají změnit, závisí na tom, jakou verzi rozhraní API pro správu používáte:

    • Pokud používáte rozhraní API V1 (/authsettings), toto nastavení je v additionalLoginParams poli.
    • Pokud používáte rozhraní API V2 (/authsettingsV2), toto nastavení je v loginParameters poli.

    Je třeba odebrat všechny odkazy na https://graph.windows.net, například. Tato změna zahrnuje resource parametr, který /v2.0 koncový bod nepodporuje. Zahrnuje také všechny obory, které výslovně požadujete ze služby Azure AD Graph.

    Musíte také aktualizovat konfiguraci a požádat o nová oprávnění Microsoft Graphu, která jste nastavili pro registraci aplikace. V mnoha případech můžete použít výchozí obor ke zjednodušení tohoto nastavení. Uděláte to tak, že přidáte nový parametr přihlášení: scope=openid profile email https://graph.microsoft.com/.default.

Při těchto změnách se při pokusu o přihlášení ověřování App Service už nebude vyžadovat oprávnění k Azure AD Graphu. Místo toho získá token pro Microsoft Graph. Veškeré použití tohoto tokenu z kódu aplikace je také potřeba aktualizovat, jak je popsáno v tématu Migrace aplikací z Azure AD Graphu do Microsoft Graphu.

Související obsah