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

Pokud chcete dostávat oznámení o aktualizacích této stránky, vložte tuto adresu URL do čtečky informačního kanálu RSS:
https://docs.microsoft.com/api/search/rss?search=%22whats%20new%20for%20authentication%22&locale=en-us

Systém ověřování průběžně mění a přidává funkce za účelem zlepšení dodržování předpisů v oblasti zabezpečení a standardů. Abyste měli přehled o nejnovějším vývoji, najdete v tomto článku informace o následujících podrobnostech:

  • Nejnovější funkce
  • Známé problémy
  • Změny protokolu
  • Zastaralé funkce

Tip

Tato stránka se pravidelně aktualizuje, proto často navštěvujte . Pokud není uvedeno jinak, jsou tyto změny zavedeny pouze pro nově zaregistrované aplikace.

Připravované změny

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

Datum platnosti: červen 2021.

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

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

Pro zvýšení zabezpečení se aktualizoval tok kódu zařízení, aby se do aplikace, kterou očekává, přidá další výzvu, která ověřuje, že se uživatel přihlašuje k aplikaci, kterou očekává. Tento soubor je přidán, aby se zabránilo útokům phishing.

Příkazový řádek, který se zobrazí, vypadá takhle:

Nová výzva při čtení "Pokoušíte se přihlásit k Azure CLI?"

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

Datum platnosti: 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

Aplikacím, které dnes používají dynamický souhlas, jsou udělena všechna oprávnění, pro která mají souhlas, i když se o to v parametru nepožádalo scope podle názvu. To může způsobit, že aplikace, která požaduje například jenom , ale se souhlasem , bude nucena předat podmíněný přístup user.read files.read přiřazený k files.read tomuto oprávnění.

Aby se snížil počet nepotřebných vývěsek podmíněného přístupu, mění Azure AD způsob, jakým se aplikacím poskytují nepožadované obory, aby podmíněný přístup spouštěly pouze explicitně požadované obory. Tato změna může způsobit přerušení aplikací, které se vztahují k předchozímu chování Azure AD (konkrétně poskytnutí všech oprávnění i v případě, že se o to nepožádalo), protože tokenům, které si vyžádají, budou chybět oprávnění.

Aplikace teď budou přijímat přístupové tokeny s kombinací oprávnění – požadovaných a také těch, pro které mají souhlas, které nevyžadují výzvy podmíněného přístupu. Obory přístupového tokenu se projeví v parametru odpovědi scope tokenu.

Tato změna bude provedena pro všechny aplikace kromě těch, které jsou na tomto chování závislé. Vývojáři dostanou výjimku, pokud jsou z této změny vyloučeni, protože mohou mít závislost na dalších příkazech podmíněného přístupu.

Příklady

Aplikace má souhlas pro user.read , files.readwrite a tasks.read . files.readwrite se na něj aplikují zásady podmíněného přístupu, zatímco u ostatních dvou ne. Pokud aplikace vytvoří požadavek na token pro a aktuálně přihlášený uživatel předal žádné zásady podmíněného přístupu, výsledný token bude pro oprávnění scope=user.read user.read a tasks.read . tasks.read je zahrnutý, protože aplikace pro něj souhlasí a nevyžaduje vynucení zásad podmíněného přístupu.

Pokud pak aplikace požaduje , spustí se podmíněný přístup vyžadované tenantem a vynutí, aby se v aplikaci zobrazí interaktivní výzva k ověření, kde je možné vyhovět zásadám scope=files.readwrite podmíněného přístupu. Vrácený token bude mít všechny tři rozsahy.

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

Květen 2020

Oprava chyby: Azure AD už nebude dvakrát kódovat parametr stavu pomocí adresy URL.

Datum platnosti: květen 2021

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

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

V odpovědi na autorizaci Azure AD byla nalezena a opravena chyba. Během ověřování je v odpovědi zahrnutý parametr z požadavku, aby se zachoval stav aplikace a pomohlo zabránit /authorize state útokům CSRF. Azure AD nesprávně zakóduje parametr url před jeho vložením do odpovědi, kde byl state znovu kódován. To by mělo za následek, že aplikace nesprávně odmítají odpověď z Azure AD.

Azure AD už nebude tento parametr dvakrát kódovat, což aplikacím umožní správně parsovat výsledek. Tato změna bude provedena pro všechny aplikace.

Azure Government koncové body se mění

Datum platnosti: 5. května (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 (AAD) pro Azure Government změnila z https://login-us.microsoftonline.com na https://login.microsoftonline.us . Tato změna se také použila Microsoft 365 GCC High a DoD, které Azure Government také služby AAD. Pokud vlastníte aplikaci v rámci tenanta státní správy USA, musíte aplikaci aktualizovat, aby se uživatelé mohli přihlašovat v koncovém .us bodě.

Od 5. května začne Azure AD vynucovat změnu koncového bodu a zablokuje 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 ). V ovlivněných aplikacích se začne zobrazit chyba AADSTS900439 - USGClientNotSupportedOnPublicEndpoint . Tato chyba znamená, ž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 ve veřejném cloudovém tenantovi a je určená k podpoře uživatelů státní správy USA, budete muset aplikaci aktualizovat tak, aby je explicitně podporovala. To může vyžadovat vytvoření nové registrace aplikace v cloudu státní správy USA.

Vynucování této změny se provádí pomocí postupného zavádění na základě toho, jak často se uživatelé z cloudu státní správy USA přihlašuje k aplikaci – aplikace, které se přihlašuje k uživatelům státní správy USA jen zřídka, se jako první zobrazí vynucení a aplikace, které uživatelé státní správy USA často používají, se nakonec vynucování použije. Očekáváme, že vynucení bude dokončeno 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 platnosti: 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 (na rozdíl od federovaného zdůstupce zabezpečení, jako je ADFS), se od 13. března 2020 nebudou moci přihlásit a místo toho budou vyzváni k resetování hesla. Správci můžou přijímat žádosti o pomoc s resetováním hesla uživatelů.

Chyba v protokolech přihlašování bude 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 jeho heslo překračuje povolenou maximální délku. Měl by se obrátit na správce, aby heslo resetoval. Pokud je pro svého tenanta povolené SSPR, může si resetovat heslo pomocí odkazu Zapomenuté heslo.

Únor 2020

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

Datum platnosti: 8. února 2020

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

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

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

Srpen 2019

Sémantika formuláře POST se bude vynucovat striktnější – mezery a uvozovky se budou ignorovat.

Datum platnosti: 2. září 2019

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

Ovlivněný protokol: Všude, kde se používá POST (přihlašovacíúdaje klienta, uplatnění autorizačního kódu, ROPC, OBOa uplatnění tokenu aktualizace)

Od 2. týdne se žádosti o ověření, které používají metodu POST, ověřují pomocí přísnějších standardů HTTP. Konkrétně se mezery a dvojité uvozovky () už nebudou z hodnot formuláře požadavku odebrané. Neočekává se, že tyto změny přeruší stávající klienty, a zajistí spolehlivé zpracování požadavků odeslaných do Azure AD. V budoucnu (viz výše) plánujeme ještě zamítnout duplicitní parametry a ignorovat BOM v rámci požadavků.

Příklad:

V současné ?e= "f"&g=h době se parsuje stejně jako ?e=f&g=h , takže e == f . S touto změnou by se teď analyzoval tak, aby – to pravděpodobně nebude platný e == "f" argument a požadavek by teď selhal.

Červenec 2019

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

Datum platnosti: 26. července 2019

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

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

  1. července se vydaná změna zabezpečení, která mění způsob, jakým se vydávají tokeny pouze pro aplikace (prostřednictvím udělení přihlašovacích údajů klienta). Dříve aplikace šly získat tokeny pro volání jakékoli jiné aplikace bez ohledu na přítomnost v tenantovi nebo rolích, se kterým u této aplikace souhlasí. Toto chování bylo aktualizováno tak, aby pro prostředky (někdy nazývané webová rozhraní API) byla nastavená na jednoho tenanta (výchozí nastavení), klientská aplikace musí existovat v rámci tenanta prostředků. Všimněte si, že stávající souhlas mezi klientem a rozhraním API se stále nevyžaduje a aplikace by měly stále provádět vlastní kontroly autorizace, aby se zajistilo, že je deklarace identity přítomná a obsahuje očekávanou hodnotu pro roles 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, vytvořte instanční objekt klientské aplikace ve vašem tenantovi pomocí prostředí souhlasu správce nebo ho vytvořte ručně. Tento požadavek zajistí, že tenant aplikaci udělil 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 aplikace s jedním tenantem s názvem pro tenanta Contoso a gateway.contoso.com/api klientská aplikace je 14c88eee-b3e2-4bb0-9233-f5e3053b3a28 . Pokud má klientská aplikace v rámci služby Contoso.com, může tento požadavek pokračovat. Pokud tomu tak ale není, požadavek selže s výše uvedenou chybou.

Pokud by ale aplikace brány Contoso byla více tenantů, požadavek by pokračoval bez ohledu na to, jestli má klientská aplikace v rámci Contoso.com.

Identifikátory URI přesměrování teď mohou obsahovat parametry řetězce dotazu.

Datum platnosti: 22. července 2019

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

Ovlivněný protokol: Všechny toky

Podle RFC 6749teď mohou aplikace Azure AD registrovat a používat identifikátory URI přesměrování (odpovědi) s parametry statického dotazu (například ) pro požadavky https://contoso.com/oauth2?idp=microsoft 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 nelze je použít k uchovávání informací o stavu v rámci požadavku na ověření – k tomu použijte state parametr .

Parametr statického dotazu podléhá porovnávání řetězců pro identifikátory 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ému redirect_uri, požadavek se zamítne. Pokud se identifikátor URI nachází v registraci aplikace, pak se k přesměrování uživatele, včetně parametru statického dotazu, použije celý řetězec.

Všimněte si, že v tuto chvíli (konec července 2019) uživatelské rozhraní registrace aplikace v Azure Portal nadále blokovat parametry dotazu. Manifest aplikace ale můžete upravit ručně, abyste mohli přidat parametry dotazu a otestovat ho ve své aplikaci.

Březen 2019

Klienti smyček budou přerušeni.

Datum platnosti: 25. března 2019

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

Ovlivněný protokol: Všechny toky

Klientské aplikace se někdy mohou zmátt a po krátkou dobu vystavovat stovky stejných žádostí o přihlášení. Tyto žádosti mohou nebo nemusí být úspěšné, ale všechny přispívají ke špatnému uživatelskému prostředí a ke zvýšení počtu úloh pro ZDDP, což zvyšuje latenci pro všechny uživatele a snižuje dostupnost ZDP. Tyto aplikace jsou v provozu mimo hranice normálního použití a měly by se aktualizovat, aby se chovaly správně.

Klientům, kteří několikrát vysílanou duplicitní požadavky, se zobrazí 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ě vyhnula. Touto chybou budou ovlivněni pouze chybně nakonfigurovaní klienti (klienti bez ukládání tokenů do mezipaměti nebo ti, kteří již vykazují smyčky příkazového řádku). Klienti se sledují místně (prostřednictvím souboru cookie) pro každou instanci podle následujících faktorů:

  • Nápověda uživatele, pokud je k nějakému dojde

  • Požadované obory nebo prostředek

  • ID klienta

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

  • Typ a režim odpovědi

Aplikacím, které za krátkou dobu (5 minut) vyžádá více požadavků (15+), se zobrazí chyba s vysvětlením, že se invalid_grant smyčkují. Požadované tokeny mají dostatečně dlouhou životnost (ve výchozím nastavení minimálně 10 minut, ve výchozím nastavení 60 minut), takže opakované žádosti za toto časové období nejsou nutné.

Všechny aplikace by se mělo zpracovat zobrazením interaktivní výzvy místo tichého invalid_grant vyžádání tokenu. Aby se této chybě vyhnuli, klienti by měli zajistit správné ukládání tokenů do mezipaměti, které dostanou.

Říjen 2018

Autorizační kódy už není možné opakovaně používat.

Datum platnosti: 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žité ověřovací kódy pro aplikace. Tato změna zabezpečení pomáhá zajistit, aby služba Azure AD byla v souladu se specifikací OAuth a vynucuje se 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 pomocí tohoto obnovovacího tokenu získat další tokeny pro jiné prostředky. Autorizační kódy je možné použít pouze jednou, ale obnovovací tokeny je možné v rámci více prostředků použít vícekrát. Každá nová aplikace, která se pokusí znovu použít ověřovací kód během toku kódu OAuth, invalid_grant chyba.

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

Květen 2018

Tokeny ID nelze 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 id_tokens nelze použít jako kontrolní výraz v toku OBO pro nové aplikace. Přístupové tokeny by se měly používat 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 si moct id_tokens přístupový token. Tento model se ale nepovažuje za osvědčený postup.

Pokud chcete tuto změnu obchádovat, můžete provést následující akce:

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