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

Microsoft pravidelně přidává a upravuje funkce platformy Microsoft Identity Platform za účelem zlepšení zabezpečení, použitelnosti a dodržování 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 být upozorněni na aktualizace 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

Říjen 2023

Aktualizace vzdáleného příkazového řádku Připojení uživatelského rozhraní

Datum účinnosti: říjen 2023

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

Ovlivněný protokol: Vzdálený Připojení

Remote Připojení je tok mezi zařízeními, který se používá pro scénáře související s Microsoft Authentication Broker a Microsoft Intune zahrnující primární obnovovací tokeny. Aby se zabránilo útokům phishing, bude tok Remote Připojení dostávat aktualizovaný jazyk uživatelského rozhraní, který bude volat, že vzdálené zařízení (zařízení, které tok zahájilo), bude mít po úspěšném dokončení toku přístup k aplikacím používaným vaší organizací.

Zobrazená výzva bude vypadat přibližně takto:

Červen 2023

Vynechání e-mailových deklarací identity s neověřeným vlastníkem domény

Datum účinnosti: červen 2023

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

Změnit

U aplikací s více tenanty se e-maily, které nejsou ověřenými vlastníky domény, ve výchozím nastavení vynechávají, když se v datové části tokenu požaduje volitelná email deklarace identity.

E-mail se považuje za ověřený vlastníkem domény, pokud:

1. Doména patří do tenanta, ve kterém se nachází uživatelský účet, a správce tenanta provedl ověření domény.
2. E-mail pochází z účtu Microsoft (MSA).
3. E-mail je z účtu Google.
4. E-mail se použil k ověřování pomocí jednorázového toku hesla (OTP).

Je také třeba poznamenat, že účty Facebook a SAML/WS-Fed nemají ověřené domény.

Květen 2023

Role správce Power BI se přejmenuje na Fabric Správa istrator.

Datum účinnosti: červen 2023

Ovlivněné koncové body:

• Výpis rolíDefinitions – Microsoft Graph v1.0
• Seznam adresářů – Microsoft Graph v1.0

Změnit

Role Správa istrator Power BI se přejmenuje na Správa istrator Fabric.

23. května 2023 společnost Microsoft představila Microsoft Fabric, která poskytuje prostředí pro integraci dat založené na službě Data Factory, přípravu dat využívající Synapse, datové sklady, datové vědy a analytické prostředí v reálném čase a business intelligence (BI) s Power BI , které jsou hostované v řešení SaaS zaměřeném na jezero. Tenant a správa kapacity pro tato prostředí jsou centralizované na portálu Fabric Správa (dříve označovaném jako portál pro správu Power BI).

Od června 2023 se role power BI Správa istratoru přejmenuje na Fabric Správa istrator, aby odpovídala měnícímu se rozsahu a odpovědnosti této role. Všechny aplikace, včetně Microsoft Entra ID, Microsoft Graph API, Microsoft 365 a GDAP, začnou odrážet nový název role během několika týdnů.

Připomínáme, že kód aplikace a skripty by se neměly rozhodovat na základě názvu role nebo zobrazovaného názvu.

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. Pokud chcete snížit četnost výskytu tohoto nesprávného přihlášení, od prosince Microsoft Entra ID odešle prompt=login parametr službě AD FS, pokud správce webových účtů ve Windows poskytuje Microsoft Entra ID login_hint během přihlašování, což znamená, že pro přihlášení je žádoucí konkrétní uživatel.

Pokud jsou splněny výše uvedené požadavky (WAM se používá k odeslání uživatele do Microsoft Entra ID pro přihlášení, login_hint zahrne se a instance služby AD FS pro doménu uživatele ) prompt=loginuživatel nebude bezobslužně přihlášený 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 mají přihlásit.

Tato změna bude provedena v prosinci 2021 během několika týdnů. Nemění chování přihlášení pro:

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

Říjen 2021

Chyba 50105 byla opravena, aby se během interaktivního 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žadování 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ůsobovala nekonečné smyčky v dobře zakódovaných aplikacích, které správně zpracovaly chybovou interaction_required odpověď. interaction_required řekne aplikaci, aby prováděla interaktivní ověřování, ale i po provedení této akce by ID Microsoft Entra vrátilo 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ď id Microsoft Entra bude uživatele uchovávat a zobrazovat přímo chybovou zprávu, což brání výskytu smyčky.

Připomínáme, že kód aplikace by neměl provádět rozhodnutí na základě řetězců kódu chyby, jako je AADSTS50105. Místo toho postupujte podle našich pokynů pro zpracování chyb a použijte standardizované odpovědi na ověřování, jako jsou interaction_required standardní errorlogin_required pole v odpovědi. Ostatní pole odpovědi jsou určená jenom pro uživatele, kteří řeší problémy.

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

V případě aplikací s jedním tenantem přidání nebo aktualizace identifikátoru URI Id appid ověří, že doména v identifikátoru URI schématu HTTPS je uvedená v seznamu ověřených domén v externím tenantovi nebo že hodnota používá výchozí schéma (api://{appId}) poskytnuté ID Microsoft Entra. To může zabránit aplikacím v přidání identifikátoru URI AppId, pokud doména není v seznamu ověřených 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á novou 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, jak je popsáno v seznamu za tabulkou.

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:// řetěd/><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:// řetěžka>.<verifiedCustomDomain>	https://product.contoso.com
<https:// řetěžka>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId – vlastnost identifikátoru aplikace (appId> ) objektu aplikace.
• <string> – hodnota řetězce pro hostitele nebo segment cesty rozhraní API.
• <tenantId> – IDENTIFIKÁTOR GUID vygenerovaný v 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 Microsoft Entra.

Poznámka:

Pokud použijete schéma api:// , přidáte řetězcovou hodnotu přímo za "api://". Například api:// řetěr>.< Tato hodnota řetězce může být IDENTIFIKÁTOR GUID nebo libovolný řetězec. Pokud přidáte hodnotu GUID, musí se shodovat s 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žít 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ů při jiných registracích 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 mají dnes udělená všechna oprávnění, pro která mají souhlas, a to i v případě, že se v parametru scope nepožadovaly 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, mění se ID Microsoft Entra způsobem, jakým se obory poskytují 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í ID Microsoft Entra, včetně všech oborů v tokenu – bez ohledu na to, jestli se jedná o požadovaný nebo ne- může dojít k přerušení kvůli chybějícím oborům.

Aplikace teď budou přijímat 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 aplikací s pozorovanou závislostí na tomto chování. Vývojáři dostanou určitou úroveň, 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 s aplikací pro user.read, files.readwritea tasks.read. files.readwrite má na něj použité zásady podmíněného přístupu, zatímco ostatní dva zásady ne. Pokud aplikace odešle žá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 dané user.read a tasks.read oprávnění. tasks.read je zahrnutá, 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ž vynutí aplikaci, aby zobrazila interaktivní výzvu k ověření, ve které se dají zásady podmíněného přístupu splnit. Vrácený token bude mít všechny tři obory.

Pokud aplikace pak provede poslední požadavek na některý ze tří oborů (řekněme), Id Microsoft Entra uvidí, scope=tasks.readž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é rozhraní 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 očekávané aplikaci.

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

Květen 2020

Oprava chyby: Id Microsoft Entra už nebude kódovat parametr stavu 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)

V odpovědi autorizace Microsoft Entra byla nalezena a opravena chyba. /authorize Během ověřování state je parametr z požadavku zahrnutý v odpovědi, aby se zachoval stav aplikace a zabránilo útokům CSRF. Microsoft Entra ID nesprávně zakódoval state adresu URL 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 ID Microsoft Entra.

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

Koncové body Azure Government se mění

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í úřad Microsoft Entra Authority pro Azure Government změnil 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 Microsoft Entra ID 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ásila uživatele na koncovém .us bodu.

5. května 2020 začne Microsoft Entra ID vynucovat změnu koncového bodu, která uživatelům státní správy blokuje přihlášení 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 s využitím 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, se nejprve zobrazí vynucení a aplikace, které uživatelé státní správy USA často používají, budou platit naposledy. Očekáváme, že v červnu 2020 se vynucuje vynucování ve všech aplikacích.

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 Microsoft Entra ID (ne k federovanému ZDP, jako je AD FS), budou vyzváni ke změně hesel, než se budou moct přihlásit. Správa mohou obdržet žádosti o pomoc s resetováním hesla uživatele.

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

Zpráva: 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 jeho heslo překračuje povolenou maximální délku. Měl by se obrátit na správce, aby resetoval heslo. Pokud je pro svého tenanta povolené samoobslužné resetování hesla, může si heslo resetovat pomocí odkazu Zapomenuté heslo.

2020. únor

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

Datum účinnosti: 8. února 2020

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

Ovlivněný protokol: Toky OAuth a OIDC, které se používají response_type=query – tok autorizačního kódu se v některých případech vztahuje na tok autorizačního kódu a implicitní tok.

Když se odešle ověřovací odpověď 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 se zajistí, ž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: v1.0 i v2.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. Konkrétně se mezery a dvojité uvozovky (") už z hodnot formuláře požadavku neodeberou. U těchto změn se neočekává, že by se přerušily žádné existující klienty, a zajistí, aby se žádosti odeslané do Microsoft Entra ID spolehlivě zpracovávaly pokaždé. V budoucnu (viz výše) plánujeme navíc odmítnout duplicitní parametry a ignorovat kusovníky v rámci požadavků.

Příklad:

Dnes, ?e= "f"&g=h je analyzován stejně jako ?e=f&g=h - tak == ef . S touto změnou by se teď parsovala tak, že e == "f" to pravděpodobně nebude platný argument a požadavek teď selže.

Červenec 2019

Tokeny pouze pro aplikace s jedním tenantem jsou vydány pouze v případě, že klientská aplikace existuje v tenantovi prostředku.

Datum účinnosti: 26. července 2019

Ovlivněné koncové body: v1.0 i v2.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 aplikacím povoleny získání tokenů 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 jednoho tenanta (výchozí nastavení), musí klientská aplikace existovat v rámci tenanta prostředku. Stávající souhlas mezi klientem a rozhraním API se stále nevyžaduje a aplikace by stále měly provádět vlastní kontroly autorizace, aby se zajistilo, že roles deklarace identity existuje 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 napravit, 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 zajišťuje, ž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=00001111-aaaa-2222-bbbb-3333cccc4444&... V tomto příkladu je tenant prostředku (autorita) contoso.com, aplikace prostředků je jednoklientská aplikace, která se volá gateway.contoso.com/api pro tenanta Contoso a klientská aplikace je 00001111-aaaa-2222-bbbb-3333cccc4444. Pokud má klientská aplikace instanční objekt v rámci Contoso.com, může tento požadavek pokračovat. Pokud to ale není, 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: v1.0 i v2.0

Ovlivněný protokol: Všechny toky

U žádostí OAuth 2.0 teď můžou aplikace Microsoft Entra podle dokumentu RFC 6749 zaregistrovat a používat identifikátory URI přesměrování (odpovědi) s parametry statického dotazu (například https://contoso.com/oauth2?idp=microsoft) pro požadavky 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 nejde ho použít k uchovávání informací o stavu v rámci žádosti o ověření – proto použijte state parametr.

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

V tuto chvíli (konec července 2019) blokuje uživatelské prostředí registrace aplikace na webu Azure Portal 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 mohou nebo nemusí být úspěšné, ale všechny přispívají ke špatnému uživatelskému prostředí a zvýšení zatížení pro IDP, zvýšení latence pro všechny uživatele a snížení dostupnosti ZDP. Tyto aplikace fungují mimo hranice normálního použití a měly by se aktualizovat tak, aby se správně chovaly.

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

Většinaklientůch Tato chyba ovlivní pouze chybně nakonfigurované klienty (klienti bez ukládání tokenů do mezipaměti nebo ti, kteří už vykazují smyčky výzvy). Klienti se sledují místně (prostřednictvím souboru cookie) na jednotlivých instancích s následujícími faktory:

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

• Požadované obory nebo prostředek

• Client ID

• URI pro přesměrování

• Typ a režim odpovědi

Aplikace provádějící více žádostí (15+) během krátkého časového období (5 minut) obdrží invalid_grant chybu s vysvětlením, že se jedná o smyčku. Požadované tokeny mají dostatečně dlouhou životnost (ve výchozím nastavení 10 minut minimálně 60 minut), takže opakované požadavky v tomto časovém období nejsou potřeba.

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 se klienti ujistit, že správně ukládají tokeny do mezipaměti, které obdrží.

2018. říjen

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 Microsoft Entra ID přijímat dříve používané ověřovací kódy pro aplikace. Tato změna zabezpečení pomáhá přenést ID Microsoft Entra do souladu se specifikací OAuth a bude vynucována na koncových bodech v1 i v2.

Pokud vaše aplikace znovu používá 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 pak tento obnovovací token použít k získání dalších tokenů pro jiné 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 pokusí znovu použít ověřovací kód během toku kódu OAuth, 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 on-behalf-of

Po 1. květnu 2018 se id_tokens nedá 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í vrstvou stejné aplikace. Aplikace zaregistrované před 1. květnem 2018 budou dál fungovat a budou moct vyměnit id_tokens pro 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ňovanou kontrolu a zabezpečení.
2. V manifestu vaší aplikace na webu Azure Portal nebo na portálu pro registraci aplikací se ujistěte, že aplikace může vydávat přístupové tokeny prostřednictvím implicitního toku. To je řízeno prostřednictvím oauth2AllowImplicitFlow klíče.
3. Když klientská aplikace požádá o id_token prostřednictvím response_type=id_token, požádejte 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.