Proč aktualizovat na Microsoft Identity Platform (v2.0)?

  • Článek

Při vývoji nové aplikace je důležité znát rozdíly mezi koncovými body Microsoft identity platform (v2.0) a Azure Active Directory (v1.0). Tento článek popisuje hlavní rozdíly mezi koncovými body a některá stávající omezení Microsoft identity platform.

Kdo se může přihlásit

Kdo se může přihlásit pomocí koncových bodů v1.0 a v2.0

  • Koncový bod verze 1.0 umožňuje přihlášení k aplikaci jenom pracovním a školním účtům (Azure AD).
  • Koncový bod Microsoft identity platform umožňuje přihlášení pracovním a školním účtům z Microsoft Entra ID a osobních účtů Microsoft (MSA), jako jsou hotmail.com, outlook.com a msn.com.
  • Oba koncové body také přijímají přihlášení uživatelů typu host z adresáře Microsoft Entra pro aplikace nakonfigurované jako jednoho tenanta nebo pro aplikace s více tenanty nakonfigurované tak, aby odkazovaly na koncový bod konkrétního tenanta (https://login.microsoftonline.com/{TenantId_or_Name}).

Koncový bod Microsoft identity platform umožňuje psát aplikace, které přijímají přihlášení z osobních účtů Microsoft a pracovních a školních účtů. Získáte tak možnost napsat aplikaci zcela nezávislou na účtu. Pokud například vaše aplikace volá Microsoft Graph, budou pro pracovní účty k dispozici některé další funkce a data, například sharepointové weby nebo data adresáře. Ale u mnoha akcí, jako je čtení pošty uživatele, může stejný kód přistupovat k e-mailu pro osobní i pracovní a školní účet.

V případě Microsoft identity platform koncového bodu můžete pomocí knihovny Microsoft Authentication Library (MSAL) získat přístup ke světu uživatelů, vzdělávání a podniků. Koncový bod Azure AD v1.0 přijímá přihlášení jenom z pracovních a školních účtů.

Aplikace používající koncový bod Azure AD v1.0 musí předem zadat požadovaná oprávnění OAuth 2.0, například:

Příklad znázorňující uživatelské rozhraní registrace oprávnění

Oprávnění nastavená přímo při registraci aplikace jsou statická. I když statická oprávnění aplikace definovaná v Azure Portal zachovat pěkný a jednoduchý kód, vývojářům to přináší několik možných problémů:

  • Aplikace musí při prvním přihlášení uživatele požádat o všechna oprávnění, která by kdy potřebovala. To může vést k dlouhému seznamu oprávnění, která koncové uživatele odradí od schválení přístupu k aplikaci při počátečním přihlášení.

  • Aplikace musí předem znát všechny prostředky, ke které by kdy přistupovala. Bylo obtížné vytvořit aplikace, které by mohly přistupovat k libovolnému počtu prostředků.

S koncovým bodem Microsoft identity platform můžete ignorovat statická oprávnění definovaná v informacích o registraci aplikace v Azure Portal a požadovat oprávnění přírůstkově, což znamená, že předem požádáte o minimální sadu oprávnění a postupně se zvyšuje, protože zákazník používá další funkce aplikace. Za tímto účelem můžete kdykoli zadat rozsahy, které vaše aplikace potřebuje, zahrnutím nových oborů do parametru scope při žádosti o přístupový token , aniž byste je museli předem definovat v informacích o registraci aplikace. Pokud uživatel ještě neudělil souhlas s novými obory přidanými do žádosti, zobrazí se mu výzva, aby udělil souhlas pouze s novými oprávněními. Další informace najdete v tématu oprávnění, souhlas a rozsahy.

Když aplikaci umožníte dynamicky vyžadovat oprávnění prostřednictvím parametru , scope získáte tak vývojářům plnou kontrolu nad uživatelským prostředím. V jedné počáteční žádosti o autorizaci můžete také předem načíst prostředí pro udělení souhlasu a požádat o všechna oprávnění. Pokud vaše aplikace vyžaduje velký počet oprávnění, můžete tato oprávnění od uživatele postupně shromažďovat, když se uživatel pokusí používat určité funkce aplikace v průběhu času.

Správa souhlas provedený jménem organizace stále vyžaduje statická oprávnění zaregistrovaná pro aplikaci, takže pokud potřebujete, aby správce dal souhlas jménem celé organizace, měli byste tato oprávnění pro aplikace nastavit na portálu pro registraci aplikací. Tím se sníží počet cyklů vyžadovaných správcem organizace k nastavení aplikace.

Obory, ne prostředky

U aplikací používajících koncový bod v1.0 se aplikace může chovat jako prostředek nebo příjemce tokenů. Prostředek může definovat řadu oborů nebo oAuth2Permissions , kterým rozumí, což klientským aplikacím umožňuje požadovat tokeny z tohoto prostředku pro určitou sadu oborů. Jako příklad prostředku vezměme Graph API Microsoft:

  • Identifikátor prostředku nebo AppID URI: https://graph.microsoft.com/
  • Obory nebo oAuth2Permissions: Directory.Read, Directory.Writeatd.

To platí pro koncový bod Microsoft identity platform. Aplikace se stále může chovat jako prostředek, definovat rozsahy a být identifikována identifikátorem URI. Klientské aplikace stále můžou požádat o přístup k těmto oborům. Způsob, jakým klient tato oprávnění požaduje, se však změnil.

U koncového bodu verze 1.0 mohl požadavek na autorizaci OAuth 2.0 na Azure AD vypadat takto:

GET https://login.microsoftonline.com/common/oauth2/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&resource=https://graph.microsoft.com/
...

Tady parametr prostředku označuje, který prostředek klientská aplikace žádá o autorizaci. Azure AD vypočítali oprávnění vyžadovaná aplikací na základě statické konfigurace v Azure Portal a odpovídajícím způsobem vystavili tokeny.

U aplikací používajících koncový bod Microsoft identity platform vypadá stejný požadavek na autorizaci OAuth 2.0 takto:

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=2d4d11a2-f814-46a7-890a-274a72a7309e
&scope=https://graph.microsoft.com/directory.read%20https://graph.microsoft.com/directory.write
...

Parametr scope tady určuje, který prostředek a oprávnění aplikace žádá o autorizaci. Požadovaný prostředek se stále nachází v požadavku – je zahrnutý v každé hodnotě parametru scope. Použití parametru oboru tímto způsobem umožňuje koncovému bodu Microsoft identity platform lépe vyhovovat specifikaci OAuth 2.0 a více odpovídá běžným postupům v odvětví. Umožňuje také aplikacím, aby udělovaly přírůstkový souhlas – o oprávnění se žádají jenom tehdy, když je aplikace vyžaduje, a nikoli předem.

Dobře známé obory

Offline přístup

Aplikace používající koncový bod Microsoft identity platform můžou vyžadovat použití nového známého oprávnění pro aplikace – offline_access obor. Všechny aplikace si budou muset vyžádat toto oprávnění, pokud potřebují přistupovat k prostředkům jménem uživatele po delší dobu, a to i v případě, že uživatel aplikaci aktivně nepoužívá. Rozsah offline_access se uživateli zobrazí v dialogových oknech souhlasu jako Přístup k datům kdykoli, se kterým musí uživatel souhlasit. Žádost o offline_access oprávnění umožní vaší webové aplikaci přijímat refresh_tokens OAuth 2.0 z koncového bodu Microsoft identity platform. Obnovovací tokeny jsou dlouhodobé a je možné je vyměnit za nové přístupové tokeny OAuth 2.0 po delší dobu přístupu.

Pokud vaše aplikace nevyžaduje offline_access obor, neobdrží obnovovací tokeny. To znamená, že při uplatnění autorizačního kódu v toku autorizačního kódu OAuth 2.0 obdržíte zpět jenom přístupový token z koncového /token bodu. Tento přístupový token zůstane platný po krátkou dobu (obvykle jednu hodinu), ale nakonec vyprší. V tomto okamžiku bude vaše aplikace muset přesměrovat uživatele zpět do koncového /authorize bodu, aby načetla nový autorizační kód. Během tohoto přesměrování může nebo nemusí uživatel v závislosti na typu aplikace znovu zadávat své přihlašovací údaje nebo se znovu přihlásit k oprávněním.

Další informace o OAuth 2.0, refresh_tokensa najdete access_tokensv referenčních informacích k protokolům Microsoft identity platform.

OpenID, profil a e-mail

V minulosti by nejzá základ přihlášení OpenID Connect s Microsoft identity platform poskytoval velké množství informací o uživateli ve výsledném id_token. Deklarace identity v id_token můžou zahrnovat jméno uživatele, upřednostňované uživatelské jméno, e-mailovou adresu, ID objektu a další.

Informace, ke kterým openid obor poskytuje přístup vaší aplikaci, jsou teď omezené. Obor openid umožní vaší aplikaci jenom přihlásit uživatele a získat pro uživatele identifikátor specifický pro aplikaci. Pokud chcete získat osobní údaje o uživateli ve vaší aplikaci, musí aplikace od uživatele požádat o další oprávnění. Dva nové obory, email a profile, vám umožní požádat o další oprávnění.

  • Obor email umožňuje vaší aplikaci přístup k primární e-mailové adrese uživatele prostřednictvím email deklarace identity v id_token za předpokladu, že uživatel má adresovatelnou e-mailovou adresu.
  • Rozsah profile poskytuje vaší aplikaci přístup ke všem ostatním základním informacím o uživateli, jako je jeho jméno, upřednostňované uživatelské jméno, ID objektu atd. v id_token.

Tyto obory umožňují naprogramovat aplikaci způsobem s minimálním zveřejněním, takže můžete uživatele požádat pouze o sadu informací, které vaše aplikace potřebuje ke své práci. Další informace o těchto oborech najdete v referenčních informacích k oboru Microsoft identity platform.

Deklarace identity tokenů

Koncový bod Microsoft identity platform ve výchozím nastavení vydává ve svých tokenech menší sadu deklarací identity, aby datové části zůstaly malé. Pokud máte aplikace a služby, které jsou závislé na konkrétní deklaraci identity v tokenu v1.0, který už není ve výchozím nastavení poskytován v tokenu Microsoft identity platform, zvažte použití volitelné funkce deklarací identity, která tuto deklaraci identity zahrne.

Důležité

Tokeny v1.0 a v2.0 mohou být vydávány koncovými body v1.0 i v2.0! id_tokens vždy odpovídat koncovému bodu, ze kterého se požaduje, a přístupové tokeny vždy odpovídají formátu očekávanému webovým rozhraním API, které bude klient volat pomocí daného tokenu. Takže pokud vaše aplikace používá koncový bod v2.0 k získání tokenu pro volání Microsoft Graphu, který očekává přístupové tokeny ve formátu v1.0, aplikace obdrží token ve formátu v1.0.

Omezení

Při používání Microsoft identity platform je potřeba mít na paměti několik omezení.

Když vytváříte aplikace, které se integrují s Microsoft identity platform, musíte se rozhodnout, jestli Microsoft identity platform koncový bod a ověřovací protokoly vyhovují vašim potřebám. Koncový bod a platforma verze 1.0 jsou stále plně podporované a v některých ohledech mají více funkcí než Microsoft identity platform. Microsoft identity platform ale vývojářům přináší značné výhody.

Tady je teď zjednodušené doporučení pro vývojáře:

  • Pokud chcete nebo potřebujete ve své aplikaci podporovat osobní účty Microsoft nebo píšete novou aplikaci, použijte Microsoft identity platform. Než to ale uděláte, ujistěte se, že rozumíte omezením popsaným v tomto článku.
  • Pokud migrujete nebo aktualizujete aplikaci, která se spoléhá na SAML, nemůžete použít Microsoft identity platform. Místo toho si projděte průvodce Azure AD v1.0.

Koncový bod Microsoft identity platform se bude vyvíjet tak, aby eliminoval zde uvedená omezení, takže vždy budete muset používat pouze koncový bod Microsoft identity platform. Mezitím podle tohoto článku zjistěte, jestli je koncový bod Microsoft identity platform pro vás ten pravý. Tento článek budeme dál aktualizovat, aby odrážel aktuální stav koncového bodu Microsoft identity platform. Vraťte se zpět a znovu vyhodnotte své požadavky oproti možnostem Microsoft identity platform.

Omezení registrace aplikací

Pro každou aplikaci, kterou chcete integrovat s koncovým bodem Microsoft identity platform, můžete vytvořit registraci aplikace v novém prostředí Registrace aplikací v Azure Portal. Stávající aplikace účtu Microsoft nejsou kompatibilní s portálem, ale všechny Microsoft Entra aplikace jsou, bez ohledu na to, kde a kdy byly zaregistrované.

Registrace aplikací, které podporují pracovní a školní účty a osobní účty, mají následující upozornění:

  • Pro každé ID aplikace jsou povoleny pouze dva tajné kódy aplikace.
  • Aplikaci, která nebyla zaregistrovaná v tenantovi, může spravovat jenom účet, který ji zaregistroval. Nelze ho sdílet s jinými vývojáři. To je případ většiny aplikací zaregistrovaných pomocí osobního účtu Microsoft na portálu pro registraci aplikací. Pokud chcete svou registraci aplikace sdílet s více vývojáři, zaregistrujte aplikaci v tenantovi pomocí nové části Registrace aplikací Azure Portal.
  • Formát adresy URL pro přesměrování, který je povolený, platí několik omezení. Další informace o adrese URL pro přesměrování najdete v další části.

Omezení adres URL pro přesměrování

Nejaktuálnější informace o omezeních adres URL pro přesměrování pro aplikace, které jsou zaregistrované pro Microsoft identity platform, najdete v tématu Omezení a omezení adres URL pro přesměrování a odpovědi v dokumentaci k Microsoft identity platform.

Informace o registraci aplikace pro použití s Microsoft identity platform najdete v tématu Registrace aplikace pomocí nového prostředí Registrace aplikací.

Omezení knihoven a sad SDK

V současné době je podpora knihovny pro koncový bod Microsoft identity platform omezená. Pokud chcete použít koncový bod Microsoft identity platform v produkční aplikaci, máte tyto možnosti:

  • Pokud vytváříte webovou aplikaci, můžete k ověření přihlášení a tokenu bezpečně použít obecně dostupný middleware na straně serveru. Patří mezi ně middleware OWIN OpenID Connect pro ASP.NET a modul plug-in Node.js Passport. Ukázky kódu, které používají middleware Microsoftu, najdete v části Začínáme s Microsoft identity platform.
  • Pokud vytváříte desktopovou nebo mobilní aplikaci, můžete použít některou z knihoven Microsoft Authentication Library (MSAL). Tyto knihovny jsou obecně dostupné nebo ve verzi Preview s podporou produkčního prostředí, takže jejich použití v produkčních aplikacích je bezpečné. Další informace o podmínkách verze Preview a dostupných knihovnách najdete v referenčních informacích o knihovnách ověřování.
  • U platforem, na které se nevztahují knihovny Microsoftu, můžete integrovat s koncovým bodem Microsoft identity platform přímým odesíláním a přijímáním zpráv protokolu v kódu aplikace. Protokoly OpenID Connect a OAuth jsou explicitně zdokumentovány , aby vám takovou integraci pomohly.
  • Nakonec můžete použít opensourcové knihovny OpenID Connect a OAuth k integraci s koncovým bodem Microsoft identity platform. Koncový bod Microsoft identity platform by měl být kompatibilní s mnoha opensourcovými knihovnami protokolů beze změn. Dostupnost těchto typů knihoven se liší podle jazyka a platformy. Weby OpenID Connect a OAuth 2.0 udržují seznam oblíbených implementací. Další informace najdete v tématu knihovny Microsoft identity platform a ověřování a seznam opensourcových klientských knihoven a ukázek, které byly testovány s koncovým bodem Microsoft identity platform.
  • Pro referenci .well-known je https://login.microsoftonline.com/common/v2.0/.well-known/openid-configurationkoncový bod pro Microsoft identity platform společný koncový bod . Nahraďte common svým ID tenanta, abyste získali data specifická pro vašeho tenanta.

Změny protokolu

Koncový bod Microsoft identity platform nepodporuje SAML ani WS-Federation, podporuje jenom OpenID Connect a OAuth 2.0. Mezi změny protokolů OAuth 2.0 z koncového bodu verze 1.0 patří:

  • Deklarace email identity se vrátí, pokud je nakonfigurovaná volitelná deklarace identity nebo byla v požadavku zadána hodnota scope=email.
  • Parametr scope se teď podporuje místo parametru resource .
  • Mnoho odpovědí bylo upraveno tak, aby byly více kompatibilní se specifikací OAuth 2.0, například se správně vrací expires_in jako int místo řetězce.

Pokud chcete lépe porozumět rozsahu funkcí protokolu podporovaných v koncovém bodu Microsoft identity platform, přečtěte si téma Referenční informace k protokolu OpenID Connect a OAuth 2.0.

Využití SAML

Pokud jste v aplikacích pro Windows používali knihovnu ADAL (Active Directory Authentication Library), možná jste využili integrované ověřování Windows, které používá udělení kontrolního výrazu SAML (Security Assertion Markup Language). Díky tomuto udělení se uživatelé federovaných Microsoft Entra tenantů můžou bezobslužně ověřovat pomocí místní Active Directory instance bez zadání přihlašovacích údajů. I když je SAML stále podporovaným protokolem pro použití s podnikovými uživateli, koncový bod verze 2.0 je určený jenom pro aplikace OAuth 2.0.

Další kroky

Další informace najdete v dokumentaci k Microsoft identity platform.