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

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ými stávajícími omezeními pro platformu Microsoft Identity Platform.

Kdo se může přihlásit

• Koncový bod verze 1.0 umožňuje přihlášení k aplikaci (Azure AD) jenom pracovním a školním účtům.
• Koncový bod platformy Microsoft Identity Platform umožňuje přihlášení k 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 jeden tenant 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ů. Díky tomu budete mít možnost psát aplikaci zcela nezávisle na účtu. Pokud například vaše aplikace volá Microsoft Graph, budou některé další funkce a data k dispozici pro pracovní účty, jako jsou třeba sharepointové weby nebo data adresáře. Pro mnoho akcí, jako je čtení pošty uživatele, ale stejný kód má přístup k e-mailu pro osobní i pracovní i školní účty.

V případě koncového bodu Microsoft Identity Platform můžete pomocí knihovny MICROSOFT Authentication Library (MSAL) získat přístup ke spotřebitelům, vzdělávacím a podnikovým světům. Koncový bod Azure AD v1.0 přijímá přihlášení jenom z pracovních a školních účtů.

Přírůstkový a dynamický souhlas

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

Oprávnění nastavená přímo v registraci aplikace jsou statická. I když statická oprávnění aplikace definované na webu Azure Portal udržují kód pěkný a jednoduchý, představují některé možné problémy pro vývojáře:

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

• Aplikace potřebuje znát všechny prostředky, ke kterých by někdy přistupovala předem. Vytváření aplikací, které by mohly přistupovat k libovolnému počtu prostředků, bylo obtížné.

Pomocí koncového bodu Microsoft Identity Platform můžete ignorovat statická oprávnění definovaná v informacích o registraci aplikace na webu Azure Portal a požadovat oprávnění přírůstkově, což znamená, že žádáte o úplné minimum sady oprávnění předem a postupně roste, protože zákazník používá další funkce aplikace. K tomu můžete kdykoli zadat rozsahy, které vaše aplikace potřebuje, tím, že při vyžádání přístupového tokenu zahrnete do parametru scope nové obory – aniž byste je museli předem definovat v informacích o registraci aplikace. Pokud uživatel ještě nepřidělil souhlas s novými obory přidanými do požadavku, zobrazí se mu výzva k vyjádření souhlasu pouze s novými oprávněními. Další informace najdete v tématu oprávnění, souhlas a obory.

Když aplikaci umožníte dynamicky vyžadovat oprávnění prostřednictvím parametru scope , získáte vývojářům plnou kontrolu nad prostředím uživatele. Můžete také zjednodušit proces získání souhlasu tím, že požádáte o všechna oprávnění jednou počáteční autorizační žádostí. Pokud vaše aplikace vyžaduje velký počet oprávnění, můžete tato oprávnění shromáždit od uživatele postupně při pokusu o používání určitých funkcí aplikace v průběhu času.

Souhlas správce provedený jménem organizace stále vyžaduje statická oprávnění zaregistrovaná pro aplikaci, takže tato oprávnění pro aplikace byste měli nastavit na portálu pro registraci aplikací, pokud potřebujete, aby správce udělil souhlas jménem celé organizace. Tím se sníží cykly, které správce organizace potřebuje 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ž umožňuje klientským aplikacím požadovat tokeny z tohoto prostředku pro určitou sadu oborů. Jako příklad prostředku zvažte rozhraní Microsoft Graph API:

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

To platí pro koncový bod Microsoft Identity Platform. Aplikace se stále může chovat jako prostředek, definovat obory 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 požaduje, aby se tato oprávnění změnila.

V případě koncového bodu verze 1.0 může žádost o autorizaci OAuth 2.0 pro 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. Služba Azure AD vypočítala oprávnění požadovaná aplikací na základě statické konfigurace na webu Azure Portal a odpovídajícím způsobem vydala tokeny.

U aplikací používajících koncový bod Microsoft Identity Platform vypadá stejná žádost o 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
...

V této části parametr oboru určuje, který prostředek a oprávnění aplikace požaduje autorizaci. Požadovaný prostředek se stále nachází v požadavku – zahrnuje každou z hodnot parametru oboru. Použití parametru oboru tímto způsobem umožňuje koncovému bodu platformy Microsoft Identity Platform lépe vyhovovat specifikaci OAuth 2.0 a lépe odpovídá běžným oborovým postupům. Umožňuje také aplikacím provádět přírůstkový souhlas – vyžaduje pouze oprávnění, když je aplikace vyžaduje, a ne předem.

Známé obory

Offline přístup

Aplikace využívající koncový bod Microsoft Identity Platform můžou vyžadovat použití nového dobře známého oprávnění pro aplikace – obor offline_access . Všechny aplikace budou muset požádat o toto oprávnění, pokud potřebují přístup k prostředkům jménem uživatele po delší dobu, i když uživatel aplikaci aktivně nepoužívá. Obor offline_access se uživateli zobrazí v dialogových oknech souhlasu jako Přístup k vašim datům kdykoli, se kterým uživatel musí 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 dají se vyměnit za nové přístupové tokeny OAuth 2.0 po delší dobu přístupu.

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

Další informace o OAuth 2.0 refresh_tokensa access_tokens, najdete v referenčních informacích k protokolu Microsoft Identity Platform.

OpenID, profil a e-mail

Většina základních přihlašovacích toků OpenID Connect s platformou Microsoft Identity Platform by v minulosti poskytovala spoustu 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 rozsah umožňuje přístup k vaší aplikaci, openid jsou teď omezené. Obor openid umožní, aby se vaše aplikace přihlásila jenom k uživateli a získala identifikátor specifický pro aplikaci. Pokud chcete získat osobní údaje o uživateli ve vaší aplikaci, musí vaše aplikace požádat o další oprávnění od uživatele. Dva nové obory email a profileumožní vám 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 má uživatel adresovatelnou e-mailovou adresu.
• Rozsah profile vaší aplikace umožňuje 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í kódovat aplikaci minimálním způsobem, abyste mohli uživatele požádat pouze o sadu informací, které vaše aplikace potřebuje k provedení své práce. Další informace o těchto oborech najdete v referenčních informacích k rozsahu platformy Microsoft Identity Platform.

Deklarace identity tokenů

Koncový bod platformy Microsoft Identity Platform ve výchozím nastavení vydává menší sadu deklarací identity v jeho tokenech, aby byla datová část malá. Pokud máte aplikace a služby, které jsou závislé na konkrétní deklaraci identity v tokenu verze 1.0, který už není ve výchozím nastavení poskytován v tokenu platformy Microsoft Identity Platform, zvažte použití volitelné funkce deklarací identity k zahrnutí této deklarace identity.

Důležité

Tokeny v1.0 a v2.0 mohou vydávat koncové body v1.0 i v2.0! id_tokens vždy odpovídají požadovanému koncovému bodu a přístupové tokeny vždy odpovídají formátu očekávanému webovým API, které váš klient bude volat pomocí daného tokenu. Pokud tedy 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í platformy Microsoft Identity Platform je potřeba mít na paměti několik omezení.

Při vytváření aplikací, které se integrují s platformou Microsoft Identity Platform, se musíte rozhodnout, jestli koncový bod platformy Microsoft Identity Platform 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 je funkce bohatší než platforma Microsoft Identity Platform. Platforma Microsoft Identity Platform ale přináší vývojářům významné výhody .

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

• Pokud chcete nebo potřebujete podporovat osobní účty Microsoft ve vaší aplikaci nebo píšete novou aplikaci, použijte platformu Microsoft Identity Platform. Než to ale uděláte, ujistěte se, že rozumíte omezením probíraným v tomto článku.
• Pokud migrujete nebo aktualizujete aplikaci, která závisí na SAML, nemůžete používat platformu 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 se eliminovala omezení uvedená tady, takže budete muset používat jenom koncový bod Microsoft Identity Platform. Do té doby můžete pomocí tohoto článku zjistit, jestli je pro vás koncový bod Microsoft Identity Platform správný. Tento článek budeme dál aktualizovat tak, aby odrážel aktuální stav koncového bodu Microsoft Identity Platform. Vraťte se zpět a znovu vyhodnocete své požadavky vůči možnostem platformy 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í na webu Azure Portal. Stávající aplikace účtů Microsoft nejsou kompatibilní s portálem, ale všechny aplikace Microsoft Entra jsou bez ohledu na to, kde nebo kdy byly zaregistrovány.

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

• Pro KAŽDÉ ID aplikace jsou povolené jenom dva tajné kódy aplikací.
• Aplikaci, která nebyla zaregistrovaná v tenantovi, může spravovat jenom účet, který ji zaregistroval. Nejde ho sdílet s ostatními vývojáři. To je případ většiny aplikací, které byly zaregistrované pomocí osobního účtu Microsoft na portálu pro registraci aplikací. Pokud chcete sdílet registraci aplikace s více vývojáři, zaregistrujte aplikaci v tenantovi pomocí nové části Registrace aplikací na webu Azure Portal.
• Formát adresy URL pro přesměrování má 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í

Informace o omezeních adres URL pro přesměrování pro aplikace zaregistrované pro platformu Microsoft Identity Platform najdete ve většině up-toinformací o omezeních a omezeních adresy URL pro přesměrování identifikátorů URI a odpovědí v dokumentaci k platformě Microsoft Identity Platform.

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

Omezení knihoven a sady SDK

V současné době je podpora knihovny koncového bodu 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ří sem 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 platformou 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 v produkční verzi Preview, takže je bezpečné je používat v produkčních aplikacích. Další informace o podmínkách verze Preview a dostupných knihovnách najdete v referenčních informacích k knihovnám ověřování.
• U platforem, které nejsou pokryty knihovnami Microsoftu, můžete integrovat koncový bod platformy Microsoft Identity Platform tak, že přímo odesíláte a přijímáte zprávy protokolu v kódu aplikace. Protokoly OpenID Connect a OAuth jsou explicitně zdokumentované , aby vám pomohly s takovou integrací.
• 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 Microsoft Identity Platform a knihovny 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 je koncový bod pro společný koncový bod platformy Microsoft Identity .well-knownhttps://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Nahraďte common 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 pouze OpenID Connect a OAuth 2.0. Mezi sledované změny protokolů OAuth 2.0 z koncového bodu v1.0 patří:

• Deklarace email se vrátí, pokud je nakonfigurovaná volitelná deklarace nebo pokud byl v požadavku uveden scope=email.
• Parametr scope je nyní podporován místo parametru resource .
• Mnoho odpovědí bylo upraveno tak, aby byly v souladu se specifikací OAuth 2.0, například správně vracely 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 referenční informace k protokolům OpenID Connect a OAuth 2.0.

Využití SAML

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

Další kroky

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