Co je nového pro ověřování?

Společnost Microsoft pravidelně přidává a upravuje funkce Microsoft identity platform, aby zlepšila dodržování předpisů v oblasti zabezpečení, použitelnosti a standardů.

Pokud není uvedeno jinak, změny popsané zde platí pouze pro aplikace zaregistrované po uvedeném datu účinnosti změny.

V tomto článku se pravidelně seznamte s následujícími informacemi:

  • Známé problémy a opravy
  • Změny protokolu
  • Zastaralé funkce

Tip

Chcete-li dostávat oznámení o aktualizacích této stránky, přidejte tuto adresu URL do čtečky informačního kanálu RSS:
https://learn.microsoft.com/api/search/rss?search=%22Azure+Active+Directory+breaking+changes+reference%22&locale=en-us

Prosinec 2021

Uživatelům služby AD FS se zobrazí další výzvy k přihlášení, aby se zajistilo, že je přihlášen správný uživatel.

Datum účinnosti: prosinec 2021

Ovlivněné koncové body: Integrované ověřování systému Windows

Ovlivněný protokol: Integrované ověřování systému Windows

Změnit

Když se dnes uživatel odešle do služby AD FS, aby se ověřil, bude bezobslužně přihlášen k libovolnému účtu, který už má relaci se službou AD FS. K tichému přihlášení dochází i v případě, že se uživatel chtěl přihlásit k jinému uživatelskému účtu. Aby se snížila frekvence tohoto nesprávného přihlášení, od prosince Azure AD odešle prompt=login parametr službě AD FS, pokud správce webových účtů ve Windows poskytuje Azure AD login_hint během přihlašování, což značí, že je pro přihlášení žádoucí konkrétní uživatel.

Pokud jsou splněny výše uvedené požadavky (WAM se používá k odeslání uživatele do Azure AD pro přihlášení, login_hint zahrne se a instance služby AD FS pro doménu uživatele podporujeprompt=login) uživatel se bezobslužně nepřihlásí a místo toho se zobrazí výzva k zadání uživatelského jména, aby se pokračovalo v přihlašování ke službě AD FS. Pokud se chtějí přihlásit ke stávající relaci služby AD FS, můžou vybrat možnost Pokračovat jako aktuální uživatel, která se zobrazí pod výzvou k přihlášení. Jinak můžou pokračovat s uživatelským jménem, pomocí kterého se chtějí přihlásit.

Tato změna bude v prosinci 2021 v průběhu několika týdnů zaváděná. Nezmění se chování při přihlašování pro:

  • Aplikace, které používají IWA přímo
  • Aplikace využívající OAuth
  • Domény, které nejsou federované do instance služby AD FS

Říjen 2021

Chyba 50105 byla opravena, aby se při interaktivním ověřování nevrátila interaction_required .

Datum účinnosti: říjen 2021

Ovlivněné koncové body: v2.0 a v1.0

Ovlivněný protokol: Všechny toky uživatelů pro aplikace vyžadující přiřazení uživatele

Změnit

Chyba 50105 (aktuální označení) se vygeneruje, když se nepřiřazený uživatel pokusí přihlásit k aplikaci, kterou správce označil jako vyžadující přiřazení uživatele. Jedná se o běžný vzor řízení přístupu a uživatelé často musí najít správce, který požádá o přiřazení k odblokování přístupu. Chyba měla chybu, která by způsobila nekonečné smyčky v dobře zakódovaných aplikacích, které správně zpracovaly interaction_required odpověď na chybu. interaction_requiredinformuje aplikaci, aby prováděla interaktivní ověřování, ale i po provedení této akce by Azure AD vrátila chybovou interaction_required odpověď.

Scénář chyby byl aktualizován, takže během neinteraktivního ověřování (kde prompt=none se používá ke skrytí uživatelského rozhraní) bude aplikace instruována k provádění interaktivního interaction_required ověřování pomocí chybové odpovědi. V následném interaktivním ověřování teď Azure AD bude uchovávat uživatele a zobrazovat přímo chybovou zprávu, která brání výskytu smyčky.

Připomínáme, že kód vaší aplikace by neměl rozhodovat na základě řetězců kódu chyb, jako je AADSTS50105. Místo toho postupujte podle našich pokynů pro zpracování chyb a používejte standardizované odpovědi na ověřování , jako jsou interaction_required standardní login_requirederror pole v odpovědi. Ostatní pole odpovědí jsou určená pouze lidmi, kteří řeší problémy.

Můžete zkontrolovat aktuální text chyby 50105 a další informace o vyhledávací službě chyby: https://login.microsoftonline.com/error?code=50105.

Identifikátor URI AppId v aplikacích s jedním tenantem bude vyžadovat použití výchozího schématu nebo ověřených domén.

Datum účinnosti: říjen 2021

Ovlivněné koncové body: v2.0 a v1.0

Ovlivněný protokol: Všechny toky

Změnit

U aplikací s jedním tenantem se přidáním nebo aktualizací identifikátoru URI Id AppId ověří, že doména v identifikátoru URI schématu HTTPS je uvedená v ověřeném seznamu domén v tenantovi zákazníka nebo že hodnota používá výchozí schéma (api://{appId}) poskytnuté Azure AD. To může aplikacím zabránit v přidání identifikátoru URI AppId, pokud doména není v ověřeném seznamu domén nebo hodnota nepoužívá výchozí schéma. Další informace o ověřených doménách najdete v dokumentaci k vlastním doménám.

Tato změna nemá vliv na stávající aplikace, které v identifikátoru URI AppID používají neověřené domény. Ověřuje pouze nové aplikace nebo když existující aplikace aktualizuje identifikátor URI nebo přidá nový do kolekce identifierUri. Nová omezení platí jenom pro identifikátory URI přidané do kolekce identifikátorů aplikace po 15. říjnu 2021. Identifikátory URI identifikátorů aplikace, které už jsou v kolekci identifikátorů aplikace, když se omezení projeví 15. října 2021, bude fungovat i v případě, že do této kolekce přidáte nové identifikátory URI.

Pokud požadavek selže při kontrole ověření, rozhraní API aplikace pro vytvoření/aktualizaci vrátí 400 badrequest klientovi, který označuje hostNameNotOnVerifiedDomain.

Podporují se následující formáty rozhraní API a identifikátoru URI ID aplikace založené na schématu HTTP. Nahraďte zástupné hodnoty podle popisu v seznamu, který následuje v tabulce.

Podporované ID aplikace
Formáty identifikátorů URI
Příklady identifikátorů URI ID aplikace
<api:// appId> api://fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
<api:// tenantId>/<appId> api://a8573488-ff46-450a-b09a-6eca0c6a02dc/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
<api:// tenantId>/<string> api://a8573488-ff46-450a-b09a-6eca0c6a02dc/api
<api:// string>/<appId> api://productapi/fc4d2d73-d05a-4a9b-85a8-4f2b3a5f38ed
<https:// tenantInitialDomain.onmicrosoft.com/>< string> https://contoso.onmicrosoft.com/productsapi
<https:// verifiedCustomDomain>/<string> https://contoso.com/productsapi
<https:// string>.< verifiedCustomDomain> https://product.contoso.com
<https:// string>.< verifiedCustomDomain>/<string> https://product.contoso.com/productsapi
  • <appId> – vlastnost identifikátoru aplikace (appId) objektu aplikace.
  • <řetězec> – hodnota řetězce pro hostitele nebo segment cesty rozhraní API.
  • <tenantId> – IDENTIFIKÁTOR GUID vygenerovaný Azure, který představuje tenanta v Rámci Azure.
  • <tenantInitialDomain tenantInitialDomain.onmicrosoft.com> - <>, kde <tenantInitialDomain> je počáteční název domény tvůrce tenanta zadaný při vytváření tenanta.
  • <verifiedCustomDomain>Ověřená vlastní doména nakonfigurovaná pro vašeho tenanta Azure AD.

Poznámka

Pokud použijete schéma api:// , přidáte řetězcovou hodnotu přímo za "api://". Například api://< string>. Tato řetězcová hodnota může být identifikátor GUID nebo libovolný řetězec. Pokud přidáte hodnotu GUID, musí odpovídat ID aplikace nebo ID tenanta. Hodnota identifikátoru URI ID aplikace musí být pro vašeho tenanta jedinečná. Pokud jako identifikátor URI ID aplikace přidáte api://< tenantId> , nikdo jiný nebude moct tento identifikátor URI používat v žádné jiné aplikaci. Doporučujeme místo toho použít api://< appId> nebo schéma HTTP.

Důležité

Hodnota identifikátoru URI ID aplikace nesmí končit znakem lomítka "/".

Poznámka

I když je bezpečné odebrat identifikátoryURI pro registrace aplikací v aktuálním tenantovi, odebrání identifikátorůUris může způsobit selhání klientů pro jiné registrace aplikací.

Srpen 2021

Podmíněný přístup se aktivuje jenom pro explicitně požadované obory.

Datum účinnosti: srpen 2021 s postupným zaváděním od dubna.

Ovlivněné koncové body: v2.0

Ovlivněný protokol: Všechny toky používající dynamický souhlas

Aplikace používající dynamický souhlas dnes mají všechna oprávnění, ke kterým mají souhlas, a to i v případě, že nebyly v parametru scope požadovány podle názvu. Aplikace, která žádá pouze user.read o souhlas files.read , může být vynucena k předání požadavku podmíněného přístupu přiřazeného files.readnapříklad.

Aby se snížil počet nepotřebných výzev podmíněného přístupu, Azure AD mění způsob, jakým jsou obory poskytovány aplikacím, takže podmíněný přístup aktivují jenom explicitně požadované obory. Aplikace, které se spoléhají na předchozí chování Azure AD zahrnutí všech oborů do tokenu – bez ohledu na to, jestli je požadováno nebo ne – může dojít k přerušení kvůli chybějícím oborům.

Aplikace teď obdrží přístupové tokeny s kombinací oprávnění: požadované tokeny a ty, které mají souhlas s výzvami podmíněného přístupu. Rozsah přístupu pro token se projeví v parametru odpovědi tokenu scope .

Tato změna se provede pro všechny aplikace s výjimkou těch, které mají pozorovanou závislost na tomto chování. Vývojáři obdrží výjimku, pokud jsou z této změny vyloučeni, protože můžou mít závislost na dalších výzev podmíněného přístupu.

Příklady

Aplikace má souhlas pro user.read, files.readwritea tasks.read. files.readwrite má pro něj zásady podmíněného přístupu, zatímco ostatní dvě zásady se na něj vztahují. Pokud aplikace vytvoří žádost o scope=user.readtoken a aktuálně přihlášený uživatel nepředá žádné zásady podmíněného přístupu, výsledný token bude pro user.read dané a tasks.read oprávnění. tasks.read je zahrnuta, protože aplikace má souhlas a nevyžaduje vynucení zásad podmíněného přístupu.

Pokud aplikace potom požádá scope=files.readwrite, aktivuje se podmíněný přístup vyžadovaný tenantem, což aplikaci vynutí, aby se zobrazila interaktivní výzva k ověření, kde je možné splnit zásady podmíněného přístupu. Vrácený token bude mít všechny tři obory.

Pokud aplikace pak provede jeden poslední požadavek na některý ze tří oborů (například scope=tasks.read), Azure AD uvidí, že uživatel už dokončil zásady podmíněného přístupu potřebné pro files.readwritea znovu vydá token se všemi třemi oprávněními.

Červen 2021

Uživatelské prostředí toku kódu zařízení teď bude obsahovat výzvu k potvrzení aplikace.

Datum účinnosti: červen 2021.

Ovlivněné koncové body: v2.0 a v1.0

Ovlivněný protokol: Tok kódu zařízení

Aby se zabránilo útokům phishing, tok kódu zařízení teď obsahuje výzvu, která ověří, že se uživatel přihlašuje k aplikaci, kterou očekává.

Výzva, která se zobrazí, vypadá takto:

Nová výzva, přečtěte si informace o tom, že se pokoušíte přihlásit k Azure CLI?

Květen 2020

Oprava chyby: Azure AD už parametr stavu nezakóduje dvakrát.

Datum účinnosti: květen 2021

Ovlivněné koncové body: v1.0 a v2.0

Ovlivněný protokol: Všechny toky, které navštíví koncový bod (implicitní tok a tok autorizačního /authorize kódu)

Byla nalezena a opravena chyba v odpovědi na autorizaci Azure AD. /authorize Během ověřování state se parametr z požadavku zahrne do odpovědi, aby se zachoval stav aplikace a zabránilo útokům CSRF. Azure AD nesprávně zakódovaný state parametr před vložením do odpovědi, kde byl kódován ještě jednou. To by vedlo k nesprávnému odmítnutí odpovědi z Azure AD.

Azure AD už tento parametr nepřekóduje, což aplikacím umožní správně analyzovat výsledek. Tato změna se provede pro všechny aplikace.

Azure Government se mění koncové body

Datum účinnosti: 5. května 2020 (dokončení června 2020)

Ovlivněné koncové body: Vše

Ovlivněný protokol: Všechny toky

Dne 1. června 2018 se oficiální autorita Azure Active Directory (Azure AD) pro Azure Government změnila na https://login-us.microsoftonline.comhttps://login.microsoftonline.us. Tato změna se vztahuje také na Microsoft 365 GCC High a DoD, které Azure Government Azure AD také služby. Pokud vlastníte aplikaci v rámci tenanta státní správy USA, musíte aplikaci aktualizovat tak, aby se přihlásili uživatelé na koncovém .us bodu.

5. května 2020 začne Azure AD vynucovat změnu koncového bodu a blokovat uživatelům státní správy přihlašování k aplikacím hostovaným v tenantech státní správy USA pomocí veřejného koncového bodu (microsoftonline.com). Ovlivněné aplikace začnou zobrazovat chybu AADSTS900439 - USGClientNotSupportedOnPublicEndpoint. Tato chyba značí, že se aplikace pokouší přihlásit uživatele státní správy USA na koncovém bodu veřejného cloudu. Pokud je vaše aplikace v tenantovi veřejného cloudu a má podporovat uživatele státní správy USA, budete muset aplikaci aktualizovat tak, aby je podporovala explicitně. To může vyžadovat vytvoření nové registrace aplikace v cloudu státní správy USA.

Vynucování této změny se provede pomocí postupného zavedení na základě toho, jak často se uživatelé z cloudu pro státní správu USA přihlašují k aplikaci – aplikace, které se přihlašují uživatelům státní správy USA zřídka, uvidí nejprve vynucení a aplikace, které uživatelé státní správy USA často používají, se budou vynucovat. Očekáváme, že se vynucování dokončí ve všech aplikacích v červnu 2020.

Další podrobnosti najdete v blogovém příspěvku Azure Government o této migraci.

Březen 2020

Uživatelská hesla budou omezena na 256 znaků.

Datum účinnosti: 13. března 2020

Ovlivněné koncové body: Vše

Ovlivněný protokol: Všechny toky uživatelů

Uživatelé s hesly delšími než 256 znaky, kteří se přihlašují přímo k Azure AD (ne federovaného protokolu IDP, například AD FS), budou požádáni o změnu hesel, než se budou moct přihlásit. Správci můžou dostávat žádosti o pomoc s resetováním hesla uživatelů.

Chyba v protokolech přihlašování bude podobná AADSTS 50052: InvalidPasswordExceedsMaxLength.

Zprávu: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Nápravných:

Uživatel se nemůže přihlásit, protože heslo překračuje povolenou maximální délku. Měli by se obrátit na správce a resetovat heslo. Pokud je pro svého tenanta povolené SSPR, může si heslo resetovat pomocí odkazu Zapomenuté heslo.

Únor 2020

Prázdné fragmenty se připojí ke každému přesměrování HTTP z koncového bodu přihlášení.

Datum účinnosti: 8. února 2020

Ovlivněné koncové body: verze 1.0 i verze 2.0

Ovlivněný protokol: toky OAuth a OIDC, které používají response_type=query – to se týká toku autorizačního kódu v některých případech a implicitního toku.

Když se ověřovací odpověď odešle z login.microsoftonline.com do aplikace přes přesměrování HTTP, služba připojí k adrese URL odpovědi prázdný fragment. Tím zabráníte třídě útoků přesměrování tím, že prohlížeč vymaže všechny existující fragmenty v žádosti o ověření. Na tomto chování by neměly být závislé žádné aplikace.

Srpen 2019

Sémantika formuláře POST se vynucuje přísněji – mezery a uvozovky budou ignorovány.

Datum účinnosti: 2. září 2019

Ovlivněné koncové body: verze 1.0 i verze 2.0

Ovlivněný protokol: Kdekoli se používá POST (přihlašovací údaje klienta, uplatnění autorizačního kódu, ROPC, OBO a uplatnění obnovovacího tokenu)

Od 2. září 2019 se ověřovací požadavky, které používají metodu POST, ověří pomocí přísnějších standardů HTTP. Mezery a dvojité uvozovky (") se už z hodnot formuláře požadavku neodeberou. Tyto změny se neočekávají, že by se přerušily žádné existující klienty, a zajistí, aby se žádosti odeslané do Azure AD spolehlivě zpracovávaly pokaždé. V budoucnu (viz výše) plánujeme navíc odmítnout duplicitní parametry a ignorovat bom v rámci požadavků.

Příklad:

Dnes se ?e= "f"&g=h parsuje stejně jako ?e=f&g=h - tak e == f. Při této změně by se teď parsovalo tak, že e == "f" - to pravděpodobně nebude platný argument a požadavek by teď selžel.

Červenec 2019

Tokeny pouze pro aplikace s jedním tenantem se vydávají pouze v případě, že klientská aplikace existuje v tenantovi prostředků.

Datum účinnosti: 26. července 2019

Ovlivněné koncové body: verze 1.0 i verze 2.0

Ovlivněný protokol: Přihlašovací údaje klienta (tokeny jen pro aplikace)

Změna zabezpečení se projevila 26. července 2019 a změnila způsob vydávání tokenů jen pro aplikace (prostřednictvím udělení přihlašovacích údajů klienta). Dříve byly aplikace povolené získat tokeny pro volání jakékoli jiné aplikace bez ohledu na přítomnost v tenantovi nebo rolích, které s touto aplikací souhlasily. Toto chování bylo aktualizováno tak, aby pro prostředky (někdy označované jako webová rozhraní API) byla nastavená na jednoklientskou (výchozí), klientská aplikace musí existovat v rámci tenanta prostředků. Stávající souhlas mezi klientem a rozhraním API se stále nevyžaduje a aplikace by měly pořád provádět vlastní kontroly autorizace, aby se zajistilo, že roles je deklarace identity přítomná a obsahuje očekávanou hodnotu rozhraní API.

Chybová zpráva pro tento scénář aktuálně uvádí:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Pokud chcete tento problém vyřešit, použijte prostředí pro vyjádření souhlasu Správa k vytvoření instančního objektu klientské aplikace ve vašem tenantovi nebo ho vytvořte ručně. Tento požadavek zajistí, že tenant udělil aplikaci oprávnění k provozu v rámci tenanta.

Příklad požadavku

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=14c88eee-b3e2-4bb0-9233-f5e3053b3a28&... V tomto příkladu je tenant prostředků (autorita) contoso.com, aplikace prostředků je jednoklientská aplikace, která se volá gateway.contoso.com/api pro tenanta Contoso a klientská aplikace je 14c88eee-b3e2-4bb0-9233-f5e3053b3a28. Pokud má klientská aplikace instanční objekt v rámci Contoso.com, může tento požadavek pokračovat. Pokud to ale nepomůže, požadavek selže s výše uvedenou chybou.

Pokud by však aplikace brány Contoso byla víceklientská aplikace, požadavek by pokračoval bez ohledu na to, jestli klientská aplikace má instanční objekt v rámci Contoso.com.

Identifikátory URI přesměrování teď můžou obsahovat parametry řetězce dotazu.

Datum účinnosti: 22. července 2019

Ovlivněné koncové body: verze 1.0 i verze 2.0

Ovlivněný protokol: Všechny toky

U požadavků OAuth 2.0 teď můžou Azure AD aplikace na RFC 6749 registrovat a používat identifikátory URI přesměrování (odpovědi) se statickými parametry dotazu (například https://contoso.com/oauth2?idp=microsoft) pro žádosti OAuth 2.0. Identifikátory URI dynamického přesměrování jsou stále zakázané, protože představují bezpečnostní riziko a nedá se použít k uchovávání informací o stavu v rámci žádosti o ověření – pro to použijte state parametr.

Parametr statického dotazu podléhá řetězcové porovnávání identifikátorů URI přesměrování stejně jako jakákoli jiná část identifikátoru URI přesměrování – pokud není zaregistrovaný žádný řetězec, který odpovídá identifikátoru URI dekódovaný redirect_uri, požadavek se odmítne. Pokud se identifikátor URI najde v registraci aplikace, použije se celý řetězec k přesměrování uživatele, včetně parametru statického dotazu.

V tuto chvíli (konec července 2019) uživatelské rozhraní registrace aplikace v Azure Portal stále blokují parametry dotazu. Manifest aplikace ale můžete upravit ručně a přidat parametry dotazu a otestovat ho v aplikaci.

Březen 2019

Klienti smyčky budou přerušeni.

Datum účinnosti: 25. března 2019

Ovlivněné koncové body: v1.0 i v2.0

Ovlivněný protokol: Všechny toky

Klientské aplikace se někdy můžou chybně chovat a za krátkou dobu vydávat stovky stejných žádostí o přihlášení. Tyto požadavky můžou nebo nemusí být úspěšné, ale všechny přispívají ke špatnému uživatelskému prostředí a vyšším úlohám pro protokol IDP, což zvyšuje latenci pro všechny uživatele a snižuje dostupnost protokolu IDP. Tyto aplikace fungují mimo hranice normálního použití a měly by se aktualizovat tak, aby se správně chovaly.

Klienti, kteří několikrát vydávají duplicitní požadavky, se odešle invalid_grant chyba: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

Většina klientů nebude muset měnit chování, aby se této chybě zabránilo. Tato chyba ovlivní pouze chybně nakonfigurované klienty (klienti bez ukládání tokenů do mezipaměti nebo ti, kteří již vykazují smyčky výzvy). Klienti se sledují místně (prostřednictvím souboru cookie) na jednotlivých instancích pomocí následujících faktorů:

  • Uživatelská nápověda, pokud existuje

  • Požadované obory nebo prostředek

  • ID klienta

  • Identifikátor URI pro přesměrování

  • Typ a režim odpovědi

Aplikace, které za krátkou dobu (5 minut) vytvářejí více požadavků (15+), obdrží invalid_grant chybu s vysvětlením, že se jedná o smyčku. Požadované tokeny mají dostatečně dlouhou životnost (minimálně 10 minut, ve výchozím nastavení 60 minut), takže opakované žádosti v tomto časovém období nejsou nutné.

Všechny aplikace by měly zpracovávat invalid_grant zobrazením interaktivní výzvy místo bezobslužné žádosti o token. Aby se zabránilo této chybě, měli by klienti zajistit správné ukládání tokenů do mezipaměti, které obdrží.

Říjen 2018

Autorizační kódy se už nedají znovu použít.

Datum účinnosti: 15. listopadu 2018

Ovlivněné koncové body: v1.0 i v2.0

Ovlivněný protokol: Tok kódu

Od 15. listopadu 2018 přestane Azure AD přijímat dříve používané ověřovací kódy pro aplikace. Tato změna zabezpečení pomáhá přenést Azure AD v souladu se specifikací OAuth a bude vynucena na koncových bodech v1 i v2.

Pokud vaše aplikace znovu použije autorizační kódy k získání tokenů pro více prostředků, doporučujeme použít kód k získání obnovovacího tokenu a potom tento obnovovací token použít k získání dalších tokenů pro další prostředky. Autorizační kódy je možné použít jenom jednou, ale obnovovací tokeny je možné použít vícekrát napříč více prostředky. Každá nová aplikace, která se během toku kódu OAuth pokusí znovu použít ověřovací kód, se zobrazí invalid_grant chyba.

Další informace o obnovovacích tokenech najdete v tématu Aktualizace přístupových tokenů. Pokud používáte knihovnu ADAL nebo MSAL, zpracuje se za vás knihovna – nahraďte druhou instanci AcquireTokenByAuthorizationCodeAsync za AcquireTokenSilentAsync.

Květen 2018

Tokeny ID nejde použít pro tok OBO.

Datum: 1. května 2018

Ovlivněné koncové body: v1.0 i v2.0

Ovlivněné protokoly: Implicitní tok a tok jménem

Po 1. květnu 2018 nelze id_tokens použít jako kontrolní výraz v toku OBO pro nové aplikace. Přístupové tokeny by se měly používat místo toho k zabezpečení rozhraní API, a to i mezi klientem a střední úrovní stejné aplikace. Aplikace zaregistrované před 1. květnem 2018 budou dál fungovat a budou moct vyměnit id_tokens za přístupový token; Tento model se ale nepovažuje za osvědčený postup.

Pokud chcete tuto změnu obejít, můžete udělat toto:

  1. Vytvořte webové rozhraní API pro vaši aplikaci s jedním nebo více obory. Tento explicitní vstupní bod umožní jemně odstupňované řízení a zabezpečení.
  2. V manifestu aplikace na Azure Portal nebo na portálu pro registraci aplikací zajistěte, aby aplikace mohl vydávat přístupové tokeny prostřednictvím implicitního toku. To je řízeno oauth2AllowImplicitFlow prostřednictvím klíče.
  3. Když klientská aplikace požádá o id_token prostřednictvím response_type=id_token, požádejte také o přístupový token (response_type=token) pro webové rozhraní API vytvořené výše. Proto při použití koncového bodu scope v2.0 by měl parametr vypadat podobně jako api://GUID/SCOPE. V koncovém bodu resource v1.0 by měl být parametr identifikátorem URI aplikace webového rozhraní API.
  4. Předejte tento přístupový token střední vrstvě místo id_token.