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 můžou nově vytvořené aplikace App Service vygenerovat jedinečný výchozí název hostitele, který používá zásady <app-name>-<random-hash>.<region>.azurewebsites.netvytváření názvů . Stávající názvy aplikací zůstávají beze změny. 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 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 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 zprostředkovatele identity pro přihlášení k Microsoftu a identitám Microsoft Entra.

  4. V části Zvolit tenanta pro vaši aplikaci a její uživatele 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 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 ta, ve které je vaše aplikace.
  • Možnost vytvoření nové registrace není dostupná pro cloudy státní správy.

Můžete vytvořit a použít novou registraci aplikace (možnost 1) nebo použít existující registraci vytvořenou samostatně (možnost 2).

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 přizpůsobit po jejím vytvoření.

Poznámka:

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

  1. Vyberte Vytvořit novou registraci aplikace.

  2. Zadejte název registrace nové aplikace.

  3. 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. 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 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 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.

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

Vyberte jednu z těchto akcí:

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

  • Zadejte 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://sts.windows.net" jako koncový bod ověřování.

Pokud potřebujete ručně vytvořit registraci aplikace v tenantovi pracovních sil, přečtěte si téma 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 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žádat 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/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 naleznete v tématu Osvědčené postupy zabezpečení pro vlastnosti aplikace v Microsoft Entra ID.

  2. Vyberte Přidat rozsah.

    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. 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. Po přechodu mimo tuto stránku se tato stránka znovu nezobrazí.

  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í 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 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.

Konfigurace nastavení ověřování

Tyto možnosti 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í 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 najdete v tématu Tok ověřování.

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. Toto chování 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í. 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 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 tématu Přidání ověřování aplikací do webové aplikace.

Autorizace žádostí

Ověřování služby App Service ve výchozím nastavení zpracovává pouze ověřování. 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í služby App Service poskytuje některé integrované kontroly, které vám můžou pomoct, ale samotné nemusí být dostatečné pro pokrytí potřeb autorizace vaší aplikace.

Tip

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 pro scénář s více tenanty nakonfigurované ověřování služby App Service, neověřuje, ze kterého tenanta pochází požadavek. 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ě. Viz Aktualizace kódu pro zpracování více hodnot vystavitelů.

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. 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 identity procházejí mapováním deklarací identity, takže názvy deklarací identity nemusí vždy odpovídat tomu, co se v tokenu zobrazí. 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. 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.

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ě 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 jako v následující struktuře:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Vlastnost Popis
defaultAuthorizationPolicy Aby bylo možné získat přístup k aplikaci, musí být splněna skupina požadavků. 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, 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 nebo azp vyhodnocuje appid příchozí token, což musí být přístupový token. Viz deklarace identity datové části.
allowedPrincipals Skupina 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ů, 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 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 deklarace identity datové části.

Některé kontroly je také možné 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ů, aaaabbbb-0000-cccc-1111-dddd2222eeeenapříklad .

Toto nastavení může vyžadovat, aby příchozí token byl z jednoho ze zadaných tenantů, jak je určeno deklarací tid identity. Nastavení WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL aplikace je možné nakonfigurovat nebo true1 vyžadovat, aby příchozí token zahrnoval oid deklaraci identity. Pokud allowedPrincipals.identities je nakonfigurované, toto nastavení se ignoruje a považuje se za true, protože oid deklarace identity se kontroluje v 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. Můžou 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. Pokud chcete ověřovat jenom uživatele, postup v této části se nevyžaduje.

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 ID.

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

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

  4. V identifikátoru URI pro přesměrování vyberte veřejný klient nebo nativní (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 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, nezapomeňte do registrace aplikace přidat user_impersonation rozsah.

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

Nakonfigurovali jste 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. 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 navigačním panelu vyberte Spravovat> 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 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 vyberte Přidat.
  9. V poli Hodnota zkopírujte hodnotu tajného klíče klienta. Po přechodu 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 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. Ověřování ve službě App Service ověřuje a používá token jako obvykle, aby teď indikoval, že volající je 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 službu App Service nebo aplikaci funkcí, kterou chcete chránit.

  2. V registraci aplikace, která představuje klienta, který 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 roli aplikace, kterou jste vytvořili dříve. Poté 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í.

    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 obsahuje roles deklaraci identity obsahující role aplikace, které byly autorizované pro klientskou aplikaci.

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. Ověřování služby App Service neprovádí toto ověření. Další informace najdete v tématu Deklarace identity uživatelů accessu.

Nakonfigurovali jste 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. Pro samostatné sloty nasazení použijte samostatné registrace aplikací. 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 nastavené se závislostí na zastaralém Azure AD Graphu, který je naplánovaný na úplné vyřazení. Kód aplikace může například volat Azure AD Graph a zkontrolovat členství ve skupině jako součást autorizačního filtru v kanálu 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:

  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), 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 https://graph.windows.netna , například. Tato změna zahrnuje resource parametr, který koncový bod nepodporuje /v2.0 , ani žádné obory, které výslovně požadujete z Azure AD Graphu.

    Musíte také 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 už při pokusu o přihlášení k ověřování ve službě App Service už nevyžaduje 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.

Další kroky