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
Č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 se uživatel přihlásil pomocí svého osobního účtu Microsoft (MSA), mohl se při registraci aplikace dříve 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ří pro umístění svých aplikací Entra a dalších prostředků Microsoftu. Uživatelé můžou snadno vytvořit nový adresář, který bude pro tento účel používat, tím , že se připojí k programu M365 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á řadu výhod. Tady jsou některé z nich:
- Aplikace zaregistrované v adresáři mají k dispozici další funkce, například možnost přidat do aplikace více než jednoho vlastníka a možnost ověřit aplikaci vydavatelem.
- Aplikace se bude nacházet na stejném místě jako jiné prostředky Microsoftu, které vývojář používá, například prostředky Azure.
- Aplikace bude dostávat vyšší výhody odolnosti.
To neovlivní žádné existující aplikace, včetně existujících aplikací, které jsou přidruženy pouze k osobnímu účtu. Bude ovlivněna pouze možnost registrace nových aplikací.
Ří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:
- Doména patří do tenanta, ve kterém se nachází uživatelský účet, a správce tenanta provedl ověření domény.
- E-mail pochází z účtu Microsoft (MSA).
- E-mail je z účtu Google.
- 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=login
už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.read
napří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.readwrite
a 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.read
token 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.readwrite
a 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á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 == e
f
. 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:
- 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í.
- 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. - 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 boduscope
v2.0 by měl parametr vypadat podobně jakoapi://GUID/SCOPE
. V koncovém boduresource
v1.0 by měl být parametr identifikátorem URI aplikace webového rozhraní API. - Předejte tento přístupový token střední vrstvě místo id_token.