Přístupové tokeny na platformě Microsoft Identity Platform

Přístupové tokeny umožňují klientům bezpečně volat chráněná webová rozhraní API. Webová rozhraní API používají přístupové tokeny k ověřování a autorizaci.

Podle specifikace OAuth jsou přístupové tokeny neprůrůzné řetězce bez nastaveného formátu. Někteří zprostředkovatelé identity (IDP) používají identifikátory GUID a jiné používají šifrované objekty blob. Formát přístupového tokenu může záviset na konfiguraci rozhraní API, které ho přijímá.

Vlastní rozhraní API registrovaná vývojáři na platformě Microsoft Identity Platform si mohou vybrat ze dvou různých formátů volaných v1.0 webových tokenů JSON (JWT) a v2.0. Rozhraní API vyvinutá Microsoftem, jako jsou Microsoft Graph nebo rozhraní API v Azure, mají jiné vlastní formáty tokenů. Tyto proprietární formáty, které nelze ověřit, můžou být šifrované tokeny, JWT nebo speciální JWT podobné.

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.

V následujících částech se dozvíte, jak rozhraní API může ověřovat a používat deklarace 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.D3H6pMUtQnoJAGq6AHd
  

• v2.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 null1 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ů aud URI 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 Připojení 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 OpenID Připojení metadat 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 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 Připojení 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 nebohttps://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:

1. 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.

2. Aplikace by měla použít issuer vlastnost vrácenou z koncového bodu klíčů k omezení rozsahu klíčů.

   • Klíče, které mají hodnotu vystavitele, jako https://login.microsoftonline.com/{tenantid}/v2.0 je, 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.0 by 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":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
       {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
       {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
     ]
   }
   

3. 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 se deklarace identity měly interpretovat v rámci tenanta stejně jako standardní openID Připojení, 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": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk",
  "kid": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk"
}

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 OpenID Připojení metadat, který se nachází 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 Připojení.
• 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žiku jwks_uri obsahuje 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žít kid deklaraci 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 x5tkid 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:

1. 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í.
2. ID tenanta (tid deklarace identity) tokenu,
3. vystavitel podpisového klíče.

Aplikace s jedním tenantem

OpenID Připojení 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é aplikace

ID Microsoft Entra také podporuje víceklientové aplikace. 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-configurationhttps://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 (tid deklarace identity tokenu).
• Ověřte, že tid deklarace identity je identifikátor GUID a iss deklarace identity je ve formuláři https://login.microsoftonline.com/{tid}/v2.0 , kde {tid} je přesná tid deklarace 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, tid deklarace 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, z dokumentu OpenID Připojení vaše aplikace přistupuje ke klíčům použitým k podepisování tokenů. Získá odpovídající dokument klíčů tak, že přistupuje k adrese URL vystavené ve vlastnosti jwks_uri dokumentu OpenId Připojení.

 "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":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","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.0 je, by se měly použít pouze v případě, že iss deklarace identity v tokenu přesně odpovídá hodnotě.
• Klíče, které mají stejnou hodnotu https://login.microsoftonline.com/{tenantid}/v2.0 vystavitele šablony, by se měly použít pouze v případě, že iss deklarace identity v tokenu odpovídá této hodnotě po nahrazení tid deklarace 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 se deklarace identity měly interpretovat v rámci tenanta stejně jako standardní openID Připojení, 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:

1. Načtení klíčů z nakonfigurované adresy URL metadat
2. Kontrola tokenu, pokud je podepsaný jedním z publikovaných klíčů, selhání, pokud ne
3. 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;
   

Viz také

• Referenční informace k deklaracím přístupového tokenu
• Zabezpečení aplikací a rozhraní API ověřováním deklarací identity

Další kroky

• Přečtěte si další informace o tokenech zabezpečení používaných v Microsoft Entra ID.