Přístupové tokeny na platformě Microsoft Identity Platform
Přístupové tokeny jsou typem tokenu zabezpečení navrženého pro autorizaci a udělení přístupu konkrétním prostředkům jménem ověřeného uživatele. Informace v přístupových tokenech určují, jestli má uživatel právo přistupovat k určitému prostředku, podobně jako klíče odemykání konkrétních dveří v budově. Tyto jednotlivé informace, které tvoří tokeny, se nazývají deklarace identity. Proto jsou citlivé přihlašovací údaje a představují bezpečnostní riziko, pokud se nezpracují správně. Přístupové tokeny se liší od tokenů ID, které slouží jako ověření.
Přístupové tokeny umožňují klientům bezpečně volat chráněná webová rozhraní API. I když klientské aplikace můžou přijímat a používat přístupové tokeny, měly by být považovány za neprůzné řetězce. Klientská aplikace by se neměla pokoušet ověřit přístupové tokeny. Server prostředků by měl přístupový token před přijetím ověřit jako doklad o autorizaci. Obsah tokenu je určený pouze pro rozhraní API, což znamená, že přístupové tokeny musí být považovány za neprůzné řetězce. Pouze pro účely ověřování a ladění můžou vývojáři dekódovat JWT pomocí webu, jako je jwt.ms. Tokeny, které rozhraní MICROSOFT API přijímá, nemusí být vždy JWT, které je možné dekódovat.
Klienti by měli použít data odpovědi tokenu vrácená pomocí přístupového tokenu, kde najdete podrobnosti o tom, co je uvnitř. Když klient požádá o přístupový token, vrátí platforma Microsoft Identity Platform také určitá metadata o přístupovém tokenu pro spotřebu aplikace. Tyto informace zahrnují dobu vypršení platnosti přístupového tokenu a rozsahy, pro které je platný. Tato data umožňují aplikaci inteligentní ukládání přístupových tokenů do mezipaměti, aniž by musela analyzovat samotný přístupový token. Tento článek vysvětluje základní informace o přístupových tokenech, včetně formátů, vlastnictví, životností a způsobu ověřování a používání deklarací identity uvnitř přístupového tokenu.
Poznámka:
Veškerá dokumentace na této stránce s výjimkou případů, kdy je uvedeno, se vztahuje pouze na tokeny vydané pro registrovaná rozhraní API. Nevztahuje se na tokeny vydané pro rozhraní API vlastněná Microsoftem ani se tyto tokeny nedají použít k ověření, jak platforma Microsoft Identity Platform vydává tokeny pro registrované rozhraní API.
Formáty tokenů
Na platformě Microsoft Identity Platform jsou k dispozici dvě verze přístupových tokenů: v1.0 a v2.0. Tyto verze určují deklarace identity, které jsou v tokenu, a ujistěte se, že webové rozhraní API může řídit obsah tokenu.
Webová rozhraní API mají při registraci vybranou jednu z následujících verzí jako výchozí:
v1.0 pro aplikace microsoft Entra-only. Následující příklad ukazuje token v1.0 (klíče se změní a osobní údaje se odeberou, což brání ověření tokenu):
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHdv2.0 pro aplikace, které podporují uživatelské účty. Následující příklad ukazuje token v2.0 (klíče se změní a osobní údaje se odeberou, což brání ověření tokenu):
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt
Nastavte verzi aplikací tak, že v manifestu aplikace poskytnete odpovídající hodnotu accessTokenAcceptedVersion nastavení. Hodnoty null 1 tokenů v1.0 a výsledek 2 v tokenech v2.0.
Vlastnictví tokenu
Požadavek na přístupový token zahrnuje dvě strany: klient, který požaduje token, a prostředek (webové rozhraní API), který token přijímá. Prostředek, pro který je token určený (jeho cílová skupina), je definován v aud deklaraci identity v tokenu. Klienti používají token, ale neměli by se ho pokoušet analyzovat nebo se je pokoušet analyzovat. Prostředky token přijímají.
Platforma Microsoft Identity Platform podporuje vydávání jakékoli verze tokenu z libovolného koncového bodu verze. Například pokud je 2hodnota accessTokenAcceptedVersion , klient volající koncový bod v1.0 získat token pro tento prostředek obdrží přístupový token v2.0.
Prostředky vždy vlastní své tokeny pomocí aud deklarace identity a jsou jedinými aplikacemi, které můžou změnit podrobnosti o tokenu.
Životnost tokenu
Výchozí životnost přístupového tokenu je proměnná. Při vydání přiřadí platforma Microsoft Identity Platform jako výchozí životnost přístupového tokenu náhodnou hodnotu v rozsahu 60 až 90 minut (v průměru 75 minut). Tato varianta zlepšuje odolnost služeb šířením poptávky po přístupových tokenech v průběhu času, což brání hodinovým špičkám v provozu do Microsoft Entra ID.
Klienti, kteří nepoužívají podmíněný přístup, mají pro klienty, jako je Microsoft Teams a Microsoft 365, výchozí životnost přístupového tokenu 2 hodiny.
Upravte dobu životnosti přístupového tokenu, abyste mohli řídit, jak často klientská aplikace vyprší platnost relace aplikace a jak často vyžaduje, aby se uživatel znovu ověřil (buď bezobslužně, nebo interaktivně). Pokud chcete přepsat výchozí variantu životnosti přístupového tokenu, použijte konfigurovatelnou životnost tokenu (CTL).
Použití výchozí varianty životnosti tokenů u organizací, které mají povolenou funkci CaE (Continuous Access Evaluation). Použijte výchozí variantu životnosti tokenu, i když organizace používají zásady CTL. Výchozí životnost tokenu pro dlouhou životnost tokenu se pohybuje od 20 do 28 hodin. Po vypršení platnosti přístupového tokenu musí klient použít obnovovací token k tichému získání nového obnovovacího tokenu a přístupového tokenu.
Organizace, které používají frekvenci přihlašování pomocí podmíněného přístupu (SIF) k vynucení četnosti výskytů přihlášení, nemůžou přepsat výchozí variantu životnosti přístupového tokenu. Když organizace používají SIF, doba mezi výzvami k zadání přihlašovacích údajů pro klienta je životnost tokenu, která se pohybuje od 60 do 90 minut a interval frekvence přihlašování.
Tady je příklad toho, jak výchozí varianta životnosti tokenu funguje s frekvencí přihlašování. Řekněme, že organizace nastaví frekvenci přihlašování každou hodinu. Pokud má token životnost od 60 do 90 minut kvůli variaci životnosti tokenu, skutečný interval přihlášení se vyskytuje kdekoli mezi 1 hodinou a 2,5 hodinami.
Pokud uživatel s tokenem s hodinovou životností provede interaktivní přihlášení za 59 minut, nezobrazí se výzva k zadání přihlašovacích údajů, protože přihlášení je pod prahovou hodnotou SIF. Pokud má nový token životnost 90 minut, uživatel neuvidí výzvu k zadání přihlašovacích údajů na další hodinu a půl. Během tichého pokusu o obnovení vyžaduje ID Microsoft Entra výzvu k zadání přihlašovacích údajů, protože celková délka relace překročila nastavení frekvence přihlášení 1 hodinu. V tomto příkladu je časový rozdíl mezi výzvami k zadání přihlašovacích údajů kvůli intervalu SIF a variantě životnosti tokenů 2,5 hodiny.
Ověření tokenů
Ne všechny aplikace by měly ověřovat tokeny. Pouze v konkrétních scénářích by aplikace měly token ověřit:
- Webová rozhraní API musí ověřovat přístupové tokeny odesílané klientem. Jako deklaraci identity musí přijímat pouze tokeny obsahující jednu z identifikátorů
audURI AppId. - Webové aplikace musí ověřovat tokeny ID odeslané do nich pomocí prohlížeče uživatele v hybridním toku, než povolí přístup k datům uživatele nebo k navázání relace.
Pokud se žádný z výše popsaných scénářů nepoužije, není potřeba token ověřit. Veřejné klienty, jako jsou nativní, desktopové nebo jednostránkové aplikace, nemají prospěch z ověřování tokenů ID, protože aplikace komunikuje přímo s protokolem IDP, kde ochrana SSL zajišťuje platnost tokenů ID. Neměly by ověřovat přístupové tokeny, protože jsou určené k ověření webového rozhraní API, ne klienta.
Rozhraní API a webové aplikace musí ověřovat pouze tokeny, které mají aud deklaraci identity, která odpovídá aplikaci. Jiné prostředky můžou mít vlastní ověřovací pravidla tokenu. Tokeny pro Microsoft Graph například nemůžete ověřit podle těchto pravidel kvůli jejich vlastnímu formátu. Ověření a přijetí tokenů určených pro jiný prostředek je příkladem zmateného problému zástupce .
Pokud aplikace potřebuje ověřit token ID nebo přístupový token, měl by nejprve ověřit podpis tokenu a vystavitele s hodnotami v dokumentu zjišťování OpenID.
Middleware Microsoft Entra má integrované funkce pro ověřování přístupových tokenů. Podívejte se na ukázky , které najdete v příslušném jazyce. K dispozici je také několik opensourcových knihoven třetích stran pro ověřování JWT. Další informace o knihovnách ověřování a ukázkách kódu najdete v knihovnách ověřování. Pokud je vaše webová aplikace nebo webové rozhraní API na ASP.NET nebo ASP.NET Core, použijte Microsoft.Identity.Web, který za vás zpracovává ověřování.
Tokeny v1.0 a v2.0
- Když vaše webová aplikace nebo rozhraní API ověřuje token v1.0 (
verdeklarace identity ="1.0"), musí číst dokument metadat OpenID Connect z koncového bodu v1.0 (https://login.microsoftonline.com/{example-tenant-id}/.well-known/openid-configuration), i když je autorita nakonfigurovaná pro vaše webové rozhraní API autorita v2.0. - Když vaše webová aplikace nebo rozhraní API ověřuje token v2.0 (
verdeklarace identity ="2.0"), musí číst dokument metadat OpenID Connect z koncového bodu v2.0 (https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration), i když je autorita nakonfigurovaná pro vaše webové rozhraní API autorita v1.0.
Následující příklady předpokládají, že vaše aplikace ověřuje přístupový token v2.0 (a proto odkazuje na verze 2.0 dokumentů a klíčů metadat OIDC). Pokud ověříte tokeny v1.0, stačí v adrese URL odebrat /v2.0.
Ověření vystavitele
OpenID Connect Core říká "Identifikátor vystavitele [...] Musí přesně odpovídat hodnotě deklarace identity iss (vystavitel). Pro aplikace, které používají koncový bod metadat specifických pro tenanta (například https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/.well-known/openid-configuration nebo https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration), je to vše, co je potřeba.
Microsoft Entra ID má verzi dokumentu nezávislou na tenantovi, která je k dispozici na adrese https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Tento koncový bod vrátí hodnotu https://login.microsoftonline.com/{tenantid}/v2.0vystavitele . Aplikace můžou tento koncový bod nezávislý na tenantovi použít k ověření tokenů z každého tenanta s následujícími úpravami:
Místo toho, aby deklarace identity vystavitele v tokenu přesně odpovídala hodnotě vystavitele z metadat, měla by aplikace nahradit
{tenantid}hodnotu v metadatech vystavitele hodnotou tenantid, která je cílem aktuálního požadavku, a pak zkontrolovat přesnou shodu.Aplikace by měla použít
issuervlastnost vrácenou z koncového bodu klíčů k omezení rozsahu klíčů.- Klíče, které mají hodnotu vystavitele, jako
https://login.microsoftonline.com/{tenantid}/v2.0je, se můžou použít s jakýmkoli odpovídajícím vystavitelem tokenu. - Klíče, které mají hodnotu vystavitele, jako
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0by se měly používat pouze s přesnou shodou.
Koncový bod klíče nezávislý na tenantovi Microsoft Entra (https://login.microsoftonline.com/common/discovery/v2.0/keys) vrátí dokument, například:
{ "keys":[ {"kty":"RSA","use":"sig","kid":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"}, {"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"}, {"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"} ] }- Klíče, které mají hodnotu vystavitele, jako
Aplikace, které používají deklaraci identity Microsoft Entra tenantid (
tid) jako hranice důvěryhodnosti místo standardní deklarace identity vystavitele, by měly zajistit, aby deklarace identity ID tenanta byla identifikátor GUID a že vystavitel a id tenanta odpovídají.
Použití metadat nezávislých na tenantovi je efektivnější pro aplikace, které přijímají tokeny z mnoha tenantů.
Poznámka:
S metadaty nezávislými na tenantovi Microsoft Entra by měly být deklarace identity interpretovány v rámci tenanta, stejně jako u standardního OpenID Connect, deklarace identity se interpretují v rámci vystavitele. To znamená a {"sub":"ABC123","iss":"https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0","tid":"aaaabbbb-0000-cccc-1111-dddd2222eeee"} {"sub":"ABC123","iss":"https://login.microsoftonline.com/bbbbcccc-1111-dddd-2222-eeee3333ffff/v2.0","tid":"bbbbcccc-1111-dddd-2222-eeee3333ffff"} popis různých uživatelů, i když je stejný sub , protože deklarace identity, jako sub jsou interpretovány v kontextu vystavitele nebo tenanta.
Ověření podpisu
JWT obsahuje tři segmenty oddělené znakem . . První segment je hlavička, druhá je tělo a třetí je podpis. K vyhodnocení pravosti tokenu použijte segment podpisu.
Microsoft Entra ID vydává tokeny podepsané pomocí standardních asymetrických šifrovacích algoritmů, jako je RS256. Hlavička JWT obsahuje informace o klíči a metodě šifrování použité k podepsání tokenu:
{
"typ": "JWT",
"alg": "RS256",
"x5t": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a",
"kid": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a"
}
Deklarace alg identity označuje algoritmus použitý k podepsání tokenu, zatímco kid deklarace identity označuje konkrétní veřejný klíč, který byl použit k ověření tokenu.
V jakémkoli okamžiku může ID Microsoft Entra podepsat token ID pomocí některé sady párů veřejného a privátního klíče. Id Microsoft Entra obměňuje možnou sadu klíčů pravidelně, takže zapište aplikaci tak, aby zpracovávala změny těchto klíčů automaticky. Přiměřenou četnost kontroly aktualizací veřejných klíčů používaných ID Microsoft Entra je každých 24 hodin.
Získejte data podpisového klíče potřebná k ověření podpisu pomocí dokumentu metadat OpenID Connect umístěného na adrese:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
Tip
Zkuste to v prohlížeči: adresa URL
Následující informace popisují dokument metadat:
- Je objekt JSON, který obsahuje několik užitečných informací, například umístění různých koncových bodů potřebných k ověřování OpenID Connect.
- Obsahuje hodnotu
jwks_uri, která poskytuje umístění sady veřejných klíčů, které odpovídají privátním klíčům používaným k podepisování tokenů. Webový klíč JSON (JWK) umístěný v tomto okamžikujwks_uriobsahuje všechny informace o veřejném klíči používané v daném okamžiku. RFC 7517 popisuje formát JWK. Aplikace může použítkiddeklaraci identity v hlavičce JWT k výběru veřejného klíče z tohoto dokumentu, který odpovídá privátnímu klíči použitému k podepsání konkrétního tokenu. Pak může provést ověření podpisu pomocí správného veřejného klíče a uvedeného algoritmu.
Poznámka:
K ověření tokenu kid použijte deklaraci identity. I když tokeny v1.0 obsahují jak x5t kid tokeny, tak deklarace identity, tokeny v2.0 obsahují pouze kid deklaraci identity.
Ověření podpisu je mimo rozsah tohoto dokumentu. Existuje mnoho opensourcových knihoven, které v případě potřeby pomáhají s ověřováním podpisů. Platforma Microsoft Identity Platform má ale jedno rozšíření podepisování tokenů pro standardy, což jsou vlastní podpisové klíče.
Pokud má aplikace vlastní podpisové klíče v důsledku použití funkce mapování deklarací identity, připojte appid parametr dotazu, který obsahuje ID aplikace. K ověření použijte jwks_uri odkaz na informace o podpisovém klíči aplikace. Například: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=00001111-aaaa-2222-bbbb-3333cccc4444 obsahuje jwks_uri hodnotu https://login.microsoftonline.com/{tenant}/discovery/keys?appid=00001111-aaaa-2222-bbbb-3333cccc4444.
Ověření vystavitele
Webové aplikace ověřující tokeny ID a webová rozhraní API ověřující přístupové tokeny musí ověřit vystavitele tokenu (iss deklarace identity) proti:
- vystavitel dostupný v dokumentu metadat připojení OpenID přidruženém ke konfiguraci aplikace (autorita). Dokument metadat, který se má ověřit, závisí na:
- verze tokenu
- účty podporované vaší aplikací.
- ID tenanta (
tiddeklarace identity) tokenu, - vystavitel podpisového klíče.
Aplikace s jedním tenantem
OpenID Connect Core říká "Identifikátor vystavitele [...] Musí přesně odpovídat hodnotě iss deklarace identity (vystavitele). Pro aplikace, které používají koncový bod metadat specifických pro tenanta, například https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration .https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration
Aplikace s jedním tenantem jsou aplikace, které podporují:
- Účty v jednom organizačním adresáři (například jenom ID tenanta):
https://login.microsoftonline.com/{example-tenant-id} - Pouze osobní účty Microsoft:
https://login.microsoftonline.com/consumers(uživatelé , kteří jsou přezdívkou pro tenanta 9188040d-6c67-4c5b-b112-36a304b66dad)
Víceklientských aplikací
Microsoft Entra ID také podporuje víceklientských aplikací. Tyto aplikace podporují:
- Účty v libovolném organizačním adresáři (jakýkoli adresář Microsoft Entra):
https://login.microsoftonline.com/organizations - Účty v libovolném organizačním adresáři (jakýkoli adresář Microsoft Entra) a osobní účty Microsoft (například Skype, XBox):
https://login.microsoftonline.com/common
Pro tyto aplikace Microsoft Entra ID zveřejňuje verze dokumentu OIDC nezávislé na tenantovi a https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration v uvedeném pořadí. Tyto koncové body vrátí hodnotu vystavitele, což je šablona parametrizovaná parametrem tenantid: https://login.microsoftonline.com/{tenantid}/v2.0. Aplikace mohou tyto koncové body nezávislé na tenantech použít k ověření tokenů z každého tenanta s následujícími ustanoveními:
- Ověření vystavitele podpisového klíče
- Místo toho, aby deklarace identity vystavitele v tokenu přesně odpovídala hodnotě vystavitele z metadat, měla by aplikace nahradit
{tenantid}hodnotu v metadatech vystavitele ID tenanta, které je cílem aktuálního požadavku, a pak zkontrolovat přesnou shodu (tiddeklarace identity tokenu). - Ověřte, že
tiddeklarace identity je identifikátor GUID aissdeklarace identity je ve formulářihttps://login.microsoftonline.com/{tid}/v2.0, kde{tid}je přesnátiddeklarace identity. Toto ověření prováže tenanta zpět k vystaviteli a zpět k rozsahu podpisového klíče, který vytváří řetězec důvěryhodnosti. - Deklarace identity použijte
tid, když vyhledá data přidružená k předmětu deklarace identity. Jinými slovy,tiddeklarace identity musí být součástí klíče použitého pro přístup k datům uživatele.
Ověření vystavitele podpisového klíče
Aplikace využívající metadata nezávislá na tenantovi v2.0 musí ověřit vystavitele podpisového klíče.
Dokument klíčů a vystavitel podpisového klíče
Jak je popsáno v dokumentu OpenID Connect, vaše aplikace přistupuje ke klíčům používaným k podepisování tokenů. Získá odpovídající dokument klíčů přístupem k adrese URL vystavené v jwks_uri vlastnosti dokumentu OpenIdConnect.
"jwks_uri": "https://login.microsoftonline.com/{example-tenant-id}/discovery/v2.0/keys",
Hodnotu {example-tenant-id} lze nahradit identifikátorem GUID, názvem domény nebo běžnými organizacemi a spotřebiteli.
Dokumenty keys vystavené službou Azure AD v2.0 obsahují pro každý klíč vystavitele, který tento podpisový klíč používá. Například koncový bod https://login.microsoftonline.com/common/discovery/v2.0/keys klíče nezávislý na tenantovi vrátí dokument, například:
{
"keys":[
{"kty":"RSA","use":"sig","kid":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
]
}
Ověření vystavitele podpisového klíče
Aplikace by měla používat issuer vlastnost dokumentu klíčů, který je přidružený ke klíči použitému k podepsání tokenu, aby omezila rozsah klíčů:
- Klíče, které mají hodnotu vystavitele s identifikátorem GUID, jako
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0je, by se měly použít pouze v případě, žeissdeklarace identity v tokenu přesně odpovídá hodnotě. - Klíče, které mají stejnou hodnotu
https://login.microsoftonline.com/{tenantid}/v2.0vystavitele šablony, by se měly použít pouze v případě, žeissdeklarace identity v tokenu odpovídá této hodnotě po nahrazenítiddeklarace identity v tokenu zástupným{tenantid}symbolem.
Použití metadat nezávislých na tenantovi je efektivnější pro aplikace, které přijímají tokeny z mnoha tenantů.
Poznámka:
S metadaty nezávislými na tenantovi Microsoft Entra by měly být deklarace identity interpretovány v rámci tenanta, stejně jako u standardního OpenID Connect, deklarace identity se interpretují v rámci vystavitele. To znamená a {"sub":"ABC123","iss":"https://login.microsoftonline.com/{example-tenant-id}/v2.0","tid":"{example-tenant-id}"} {"sub":"ABC123","iss":"https://login.microsoftonline.com/{another-tenand-id}/v2.0","tid":"{another-tenant-id}"} popis různých uživatelů, i když je stejný sub , protože deklarace identity, jako sub jsou interpretovány v kontextu vystavitele nebo tenanta.
Rekapitulace
Tady je nějaký pseudokód, který přepíše, jak ověřit vystavitele a podpisového vystavitele klíče:
- Načtení klíčů z nakonfigurované adresy URL metadat
- Kontrola tokenu, pokud je podepsaný jedním z publikovaných klíčů, selhání, pokud ne
- Identifikujte klíč v metadatech na základě hlavičky dítěte. Zkontrolujte vlastnost vystavitele připojenou k klíči v dokumentu metadat:
var issuer = metadata["kid"].issuer; if (issuer.contains("{tenantId}", CaseInvariant)) issuer = issuer.Replace("{tenantid}", token["tid"], CaseInvariant); if (issuer != token["iss"]) throw validationException; if (configuration.allowedIssuer != "*" && configuration.allowedIssuer != issuer) throw validationException; var issUri = new Uri(token["iss"]); if (issUri.Segments.Count < 1) throw validationException; if (issUri.Segments[1] != token["tid"]) throw validationException;