Sdílet prostřednictvím

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

  • Článek

Poznámka:

Od 1. června 2024 budou mít všechny nově vytvořené aplikace App Service možnost vytvořit jedinečný výchozí název hostitele s konvencí <app-name>-<random-hash>pojmenování .<region>..azurewebsites.net Názvy existujících aplikací se nezmění.

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

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

Vyberte jiného zprostředkovatele ověřování a přejděte na něj.

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

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

Než se vaše aplikace může přihlásit k uživatelům, musíte ji nejdřív zaregistrovat v pracovní síle nebo externím tenantovi. Pokud aplikaci zpřístupňujete zaměstnancům nebo obchodním hostům, zaregistrujte aplikaci v tenantovi pracovních sil. 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 k webu Azure Portal a přejděte do aplikace.

  2. V nabídce vlevo vaší aplikace vyberte Ověřování a pak vyberte Přidat zprostředkovatele identity.

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

  4. Jako typ tenanta vyberte Konfiguraci pracovních sil (aktuální tenant) pro zaměstnance a firemní hosty nebo vyberte Externí konfiguraci pro uživatele a firemní zákazníky.

Volba registrace aplikace

Funkce ověřování služby App Service může automaticky vytvořit registraci aplikace za vás nebo můžete použít registraci, kterou jste vy nebo správce adresáře vytvořili 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 ta, ve které je vaše aplikace.
  • Možnost vytvoření nové registrace není dostupná pro cloudy státní správy.

Vytvořte a použijte novou registraci aplikace nebo použijte existující registraci vytvořenou samostatně.

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

Tuto možnost použijte, pokud nepotřebujete vytvořit registraci aplikace samostatně. Registraci aplikace v Microsoft Entra můžete po vytvoření přizpůsobit.

Poznámka:

Možnost vytvořit novou registraci automaticky není dostupná pro cloudy státní správy. Místo toho definujte registraci samostatně.

Zadejte název registrace nové aplikace.

Vyberte typ podporovaného účtu:

  • Aktuální tenant – jeden tenant Účty 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íceklient. Úč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. To zahrnuje š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 adresáři organizace a osobních účtech Microsoft (například Skype, Xbox). Vaši aplikaci nebo rozhraní API můžou používat všichni uživatelé s pracovním nebo školním nebo osobním účtem Microsoft. Zahrnuje školy a firmy, které používají Office 365, i 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 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 spravovat tajný klíč ve službě Azure Key Vault, můžete toto nastavení později aktualizovat tak, aby používalo odkazy na službu Key Vault.

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

Buď:

  • Vyberte v tomto adresáři existující registraci aplikace a v rozevíracím seznamu vyberte registraci aplikace.
  • Vyberte Zadat podrobnosti o stávající registraci aplikace a 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 vyžádání tokenu. Tato hodnota se uloží do konfigurace aplikace jako nastavení MICROSOFT_PROVIDER_AUTHENTICATION_SECRETaplikace s názvem 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ý se nedoporučuje.
    • Adresa URL vystavitele, která má tvar <authentication-endpoint>/<tenant-id>/v2.0. Nahraďte <authentication-endpoint> hodnotou koncového bodu ověřování specifickou pro cloudové prostředí. Například tenant pracovních sil v globálním Azure by používal "https://login.microsoftonline.com" jako koncový bod ověřování.

Pokud potřebujete ručně vytvořit registraci aplikace v tenantovi pracovních sil, postupujte podle rychlého startu registrace aplikace . Při procházení procesu registrace nezapomeňte poznamenat ID aplikace (klienta) a hodnoty tajných kódů klienta.

Během procesu registrace vyberte v části Identifikátory URI přesměrování web pro platformu a typ <app-url>/.auth/login/aad/callback. Například https://contoso.azurewebsites.net/.auth/login/aad/callback.

Po vytvoření upravte registraci aplikace:

  1. V levém navigačním panelu 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 vyžádání tokenů, které udělují přístup. Používá se jako předpona pro vytvořené obory.

    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/api na 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 najdete v referenčních informacích k osvědčeným postupům registrace aplikací.

  2. Vyberte Přidat rozsah.

    1. Do pole Název oboru zadejte user_impersonation.
    2. V Kdo může souhlasit, vyberte Správa a uživatele, pokud chcete uživatelům povolit souhlas s tímto oborem.
    3. Do textových polí zadejte název oboru souhlasu a popis, který mají uživatelé vidět na stránce souhlasu. Zadejte například název> aplikace accessu<.
    4. Vyberte Přidat rozsah.

  3. (Doporučeno) Vytvoření tajného klíče klienta:

    1. V levém navigačním panelu vyberte Certifikáty a tajné klíče>>klienta Nové tajné klíče klienta.
    2. Zadejte popis a vypršení platnosti a vyberte Přidat.
    3. V poli Hodnota zkopírujte hodnotu tajného klíče klienta. Jakmile přejdete mimo tuto stránku, znovu se nezobrazí.

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

Konfigurace dalších kontrol

Nakonfigurujte další kontroly, které určují, které požadavky mají povolený přístup k vaší aplikaci. Toto chování teď můžete přizpůsobit nebo později upravit tato nastavení z hlavní obrazovky Ověřování tak, že zvolíte Upravit vedle nastavení ověřování.

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

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

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

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

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

  • Povolit žádosti pouze z tenanta vystavitele
  • Povolit žádosti od konkrétních tenantů
  • Použití výchozích omezení na základě vystavitele

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

Konfigurace nastavení ověřování

Tyto možnosti určují, jak vaše aplikace reaguje na neověřené požadavky, a výchozí výběry přesměrují všechny žádosti, aby se přihlásily pomocí tohoto nového poskytovatele. Toto chování můžete nyní změnit nebo později upravit tato nastavení z hlavní obrazovky Ověřování tak, že zvolíte Upravit vedle nastavení ověřování. Další informace o těchtomožnostch

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

  • Vyžadování ověřování
  • Povolit neověřený přístup

Pro neověřené požadavky

  • Http 302 Nalezeno přesměrování: doporučeno pro weby
  • HTTP 401 Neautorizováno: Doporučeno pro rozhraní API
  • HTTP 403 – Zakázáno
  • HTTP 404 Nenalezena

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

Přidání 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 potřebná aplikací. Ty 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 bude uveden na obrazovce 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 tomto kurzu.

Autorizace žádostí

Ověřování služby App Service ve výchozím nastavení zpracovává pouze ověřování a zjišťuje, jestli je volající tím, o koho se jedná. Autorizace, která určuje, jestli má volající mít přístup k určitému prostředku, je dodatečný krok nad rámec ověřování. Další informace o těchto konceptech najdete v základech autorizace platformy Microsoft Identity Platform.

Vaše aplikace může rozhodovat o autorizaci v kódu. Ověřování služby App Service poskytuje některé integrované kontroly, které vám můžou pomoct, ale nemusí být dostatečné k pokrytí potřeb autorizace vaší aplikace.

Tip

Aplikace s více tenanty 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 možná omezená na konkrétní tenanty, a to na základě toho, jestli se například organizace zaregistrovala ke službě. Přečtěte si pokyny k víceklientovi platformy Microsoft Identity Platform.

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 deklarací identity, které zpřístupňuje ověřování služby App Service. 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 identity procházejí mapováním deklarací identity, takže názvy deklarací identity nemusí vždy odpovídat tomu, co byste viděli v tokenu. Deklarace identity je například tid namapovaná na http://schemas.microsoft.com/identity/claims/tenantid místo toho.

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, což je v pořádku pro mnoho aplikací. Některé aplikace ale potřebují přístup dál omezit tím, že se budou rozhodovat 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.

V této části se dozvíte, 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ě prostřednictvím š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 jako v následující struktuře:

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

Tato zásada vyhodnocuje nebo azp vyhodnocuje appid příchozí token, což musí být přístupový token. Viz referenční informace k deklaracím identity platformy Microsoft Identity Platform.
allowedPrincipals Seskupení kontrol, které určují, jestli objekt zabezpečení reprezentovaný příchozím požadavkem má přístup k aplikaci. allowedPrincipals Spokojenost je založena na logické OR nad nakonfigurovanými vlastnostmi.
identities (v části allowedPrincipals) Seznam povolených ID objektů řetězců představujících uživatele nebo aplikace, které mají přístup. 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 reprezentovaná požadavkem zadána v seznamu. V seznamu identit je limit 500 znaků celkem.

Tato zásada vyhodnocuje oid deklaraci příchozího tokenu. Viz referenční informace k deklaracím identity platformy Microsoft Identity Platform.

Kromě toho je možné některé kontroly nakonfigurovat prostřednictvím nastavení aplikace bez ohledu na používanou verzi rozhraní API. Nastavení WEBSITE_AUTH_AAD_ALLOWED_TENANTS aplikace lze nakonfigurovat pomocí čárkami odděleného seznamu až 10 ID tenantů (například "559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc") vyžaduje, aby příchozí token byl z jednoho z určených tenantů, jak je určeno tid deklarací identity. Nastavení WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL aplikace je možné nakonfigurovat na hodnotu true nebo 1, aby vyžadovalo zahrnutí deklarace identity příchozím tokenem oid . Toto nastavení se ignoruje a považuje se za true, pokud allowedPrincipals.identities je nakonfigurované (protože oid se deklarace identity kontroluje na tomto poskytnutém seznamu identit).

Požadavky, které tyto integrované kontroly selžou, mají odpověď HTTP 403 Forbidden .

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

V předchozích částech jste zaregistrovali službu App Service nebo funkci Azure Functions k ověřování uživatelů. Tato část vysvětluje, jak registrovat nativní klienty nebo aplikace démona v Microsoft Entra, aby mohli požádat o přístup k rozhraním API vystaveným vaší službou App Service jménem uživatelů nebo samotných, například v N-úrovňové architektuře. Dokončení kroků v této části se nevyžaduje, pokud chcete pouze ověřovat uživatele.

Nativní klientská aplikace

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

  1. V nabídce portálu vyberte Microsoft Entra.

  2. V levém navigačním panelu vyberte Registrace aplikací> Nová registrace.

  3. Na stránce Registrace aplikace zadejte název registrace aplikace.

  4. V identifikátoru URI přesměrování vyberte Veřejný klient (mobilní &desktop) a zadejte adresu URL <app-url>/.auth/login/aad/callback. Například 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 identifikátor SID balíčku jako identifikátor URI.

  7. V levém navigačním panelu vyberte oprávnění>rozhraní API 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 rozsah 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í služby App Service nebo aplikace funkcí 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.

  1. V nabídce portálu vyberte Microsoft Entra.
  2. V levém navigačním panelu vyberte Registrace aplikací> Nová registrace.
  3. Na stránce Registrace aplikace zadejte název registrace aplikace.
  4. Pro aplikaci démona nepotřebujete identifikátor URI přesměrování, abyste mohli zachovat tento prázdný identifikátor.
  5. Vyberte Zaregistrovat.
  6. Po vytvoření registrace aplikace zkopírujte hodnotu ID aplikace (klienta).
  7. V levém navigačním panelu vyberte Certifikáty a tajné klíče>>klienta Nové tajné klíče klienta.
  8. Zadejte popis a vypršení platnosti a vyberte Přidat.
  9. V poli Hodnota zkopírujte hodnotu tajného klíče klienta. Jakmile přejdete mimo tuto stránku, znovu se nezobrazí.

Teď můžete požádat o přístupový token pomocí ID klienta a tajného klíče klienta nastavením resource parametru na identifikátor URI ID aplikace cílové aplikace. Výsledný přístupový token se pak dá cílové aplikaci předložit pomocí standardní autorizační hlavičky OAuth 2.0 a ověřování služby App Service ověří a použije token jako obvykle, aby teď indikoval, že volající (aplikace v tomto případě není uživatel) ověřený.

V současné době to umožňuje , aby jakákoli klientská aplikace ve vašem tenantovi Microsoft Entra požadovala přístupový token a ověřila se 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 představující app Service nebo aplikaci funkcí, kterou chcete chránit.
  2. V registraci aplikace představujícího klienta, kterého je potřeba autorizovat, vyberte oprávnění rozhraní API Př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 a pak vyberte Přidat oprávnění.
  5. Ujistěte se, že jste vybrali možnost Udělit správci souhlas s autorizaci klientské aplikace a požádejte o oprávnění.
  6. Podobně jako v předchozím scénáři (před přidáním všech rolí) teď můžete požádat o přístupový token pro stejný cíl resourcea přístupový token bude obsahovat roles deklaraci identity obsahující role aplikace, které byly autorizované pro klientskou aplikaci.
  7. V rámci cílové služby App Service nebo kódu aplikace funkcí teď můžete ověřit, že v tokenu existují očekávané role (to neprovádí ověřování služby App Service). Další informace najdete v tématu Deklarace identity uživatelů accessu.

Právě jste nakonfigurovali klientskou aplikaci démona, která má přístup 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í:

  • Nakonfigurujte každou aplikaci App Service 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 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é ovlivňují produkční aplikaci.

Migrace do Microsoft Graphu

Některé starší aplikace můžou být také nastavené se závislostí na zastaralém Azure AD Graphu, který je naplánovaný na úplné vyřazení. Kód vaší aplikace se například může jmenovat Azure AD Graph, který kontroluje členství ve skupinách jako součást autorizačního filtru v kanálu middlewaru. Aplikace by se měly přesunout do Microsoft Graphu podle pokynů poskytovaných Microsoft Entra v rámci procesu vyřazení Azure AD Graphu. V následujících pokynech možná budete muset provést určité změny konfigurace ověřování služby App Service. Po přidání oprávnění Microsoft Graphu k registraci aplikace můžete:

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

  2. 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), bude to v additionalLoginParams poli.
    • Pokud používáte rozhraní API V2 (/authsettingsV2), bude to v loginParameters poli.

    Je třeba odebrat všechny odkazy na "https://graph.windows.net", například. To zahrnuje resource parametr (který koncový bod /v2.0 nepodporuje) nebo jakékoli obory, které konkrétně požadujete z Azure AD Graphu.

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

Při těchto změnách se při pokusu o přihlášení k ověřování služby App Service už nebude vyžadovat oprávnění k Azure AD Graphu a místo toho získá token pro Microsoft Graph. Jakékoli použití tohoto tokenu z kódu vaší aplikace by také bylo potřeba aktualizovat podle pokynů poskytovaných společností Microsoft Entra.

Další kroky