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

Srpen 2024

Přihlašovací údaje federované identity teď používají porovnávání s rozlišováním velkých a malých písmen.

Datum účinnosti: září 2024

Ovlivněný protokol: Federace identit úloh

Změnit

Dříve se při porovnávání přihlašovacích údajů federované identity (FIC) issuersubjecta audience hodnot odpovídajících issuersubjecthodnot a audience hodnot obsažených v tokenu odeslaném do Microsoft Entra ID externího zprostředkovatele identity použilo porovnávání bez rozlišování velkých a malých písmen. Abychom zákazníkům poskytli jemněji odstupňovanou kontrolu, přecházíme na vynucování porovnávání s rozlišováním velkých a malých písmen.

Neplatný příklad:

• Předmět tokenu: repo:contoso/contoso-org:ref:refs/heads/main
• Předmět FIC: repo:Contoso/Contoso-Org:ref:refs/heads/main

Tyto dvě hodnoty předmětu se nerozlišují malá a velká písmena, takže ověření selže. Stejný mechanismus se použije u issuer a audience ověření.

Tato změna se použije zpočátku u aplikací nebo spravovaných identit vytvořených po August 14th, 2024. Neaktivní aplikace nebo spravované identity určené nulovou federací identit úloh odvíjejí od zmíněné aplikace nebo spravované identity mezi obdobím August 1st, 2024 August 31st, 2024, jsou vyžadovány k použití porovnávání s rozlišováním velkých a malých písmen počínaje September 27th, 2024. U aktivních aplikací přichází párování nerozlišující malá a velká písmena k pozdějšímu datu, které se má sdělit.

Abychom lépe zvýraznili chyby způsobené rozlišováním malých a velkých písmen, přepracujeme chybovou zprávu pro AADSTS700213. Nyní bude uvedeno;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

Zástupný symbol '{subject}' poskytuje hodnotu deklarace subjektu obsažené v tokenu, který se odesílá z externího zprostředkovatele identity do Microsoft Entra ID. Tato šablona chyby se také používá pro případ nerozlišující chyby kolem issuer a audience ověřování. Pokud dojde k této chybě, měli byste najít přihlašovací údaje federované identity, které odpovídají hodnotě issuer, subjectnebo audience uvedené v chybě a potvrdit, že odpovídající hodnoty jsou ekvivalentní z hlediska rozlišování velkých a malých písmen. Pokud dojde k neshodě, musíte nahradit aktuální issuerhodnotu , subjectnebo audience hodnotu ve FIC issuerhodnotou , subjectnebo audience hodnotou, která byla obsažena v chybové zprávě.

Poznámka:

Pro zákazníky se službou Aplikace Azure Service, kteří používají GitHub Actions a dochází k této chybě, je možnost pro vyřešení tohoto problému přejít do souboru /.github/workflows pracovního postupu v úložišti GitHub a aktualizovat vlastnost prostředí name z "Production" umístění na "production". Tyto pokyny platí jenom pro scénáře služby Aplikace Azure. Pokud k této chybě dochází v jiném scénáři, projděte si výše uvedené pokyny.

Červen 2024

Aplikace musí být zaregistrované v adresáři.

Datum účinnosti: červen 2024

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

Ovlivněný protokol: Všechny toky

Změnit

Pokud byl uživatel přihlášený pomocí svého osobního účtu Microsoft (MSA), při registraci aplikace pomocí registrace aplikace Microsoft Entra se dříve mohl rozhodnout, že aplikaci přidruží jenom ke svému osobnímu účtu. To znamená, že aplikace by nebyla přidružená k žádnému adresáři (označované také jako "tenant" nebo "organization"). Od června 2024 ale musí být všechny aplikace zaregistrované v adresáři. Může se jednat o existující adresář nebo nový, který uživatel osobního účtu Microsoft vytvoří, aby mohl zamístit své aplikace Microsoft Entra a další prostředky Microsoftu. Uživatelé můžou snadno vytvořit nový adresář, který bude pro tento účel používat, když se připojí k programu Microsoft 365 Developer Program nebo se zaregistrují do Azure.

Registrace aplikace v adresáři, místo toho, aby ji přidružovala jenom k osobnímu účtu, má různé výhody. Tady jsou některé z nich:

• Aplikace zaregistrované v adresáři mají k dispozici více funkcí, například možnost přidat do aplikace více než jednoho vlastníka a možnost ověřit aplikaci vydavatelem.
• Aplikace se nachází na stejném místě jako jiné prostředky Microsoftu, které vývojář používá, například prostředky Azure.
• Aplikace získá lepší výhody odolnosti.

To neovlivní žádné existující aplikace, včetně existujících aplikací, které jsou přidružené pouze k osobnímu účtu. Bude ovlivněna pouze možnost registrace nových aplikací.

Říjen 2023

Aktualizace výzvy uživatelského rozhraní RemoteConnect

Datum účinnosti: říjen 2023

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

Ovlivněný protokol: RemoteConnect

RemoteConnect 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, přijímá tok RemoteConnect aktualizovaný jazyk uživatelského rozhraní, aby volal, ž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 Správce prostředků infrastruktury.

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ávce Power BI se přejmenuje na Správce prostředků infrastruktury.

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 pro správu prostředků infrastruktury (dříve označovaném jako portál pro správu Power BI).

Od června 2023 se role správce Power BI přejmenuje na Správce prostředků infrastruktury, 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í error login_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 AppId ověří, že doména v identifikátoru URI schématu HTTPS je uvedená v seznamu ověřených domén v tenantovi zákazníka 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://00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
<api:// tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
<api:// řetěd/><appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
<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.com https://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ávci můžou obdržet žádosti o resetování 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áprava:

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í souhlasu správce 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.