Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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 ke konkrétní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 s nimi zacházet jako s neprůzrnostmi řetězci. Klientská aplikace by se neměla pokoušet ověřit přístupové tokeny. Server zdrojů by měl před přijetím přístupového tokenu za důkaz autorizace ověřit jeho platnost. 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 z odpovědi tokenu vrácená spolu s přístupovým tokenem, kde najdou podrobnosti o tom, co obsahuje. 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í claimy, které jsou v tokenu, a zajišťují, aby webové API mohlo řídit obsah tokenu.
Webová rozhraní API mají při registraci vybranou jednu z následujících verzí jako výchozí:
v1.0 pouze pro aplikace Microsoft Entra. 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í zadáním odpovídající hodnoty do nastavení requestedAccessTokenVersion v souboru manifestu aplikace. Hodnoty null a 1 vedou k tokenům v1.0 a hodnota 2 vede k tokenům 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á. Zdroj, pro který je token určen (jeho příjemce), je definován v atributu aud tokenu. Klienti token používají, ale neměli by mu rozumět ani se jej pokoušet parsovat. Zdroje přijímají token.
Platforma Microsoft Identity podporuje vydávání jakékoli verze tokenu z jakéhokoli koncového bodu verze. Například pokud má requestedAccessTokenVersion hodnotu 2, klient, který volá koncový bod v1.0 za účelem získání tokenu pro tento prostředek, obdrží přístupový token v2.0.
Prostředky vždy vlastní své tokeny pomocí claimu aud a jsou jedinými aplikacemi, které mohou měnit podrobnosti svých tokenů.
Ž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 může být v rozsahu od intervalu frekvence přihlašování až po dobu života 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. Musí přijímat pouze tokeny obsahující jako claim
audjeden ze svých identifikátorů 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 smí ověřovat pouze tokeny, které mají claim aud, jenž odpovídá dané 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ěřování a přijímání tokenů určených pro jiný zdroj je příkladem problému zmateného zástupce.
Pokud aplikace potřebuje ověřit ID token nebo přístupový token, měla by nejprve ověřit podpis tokenu a údaj o vystaviteli podle hodnot uvedených ve zjišťovacím dokumentu 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/API ověřuje token v1.0 (
verclaim ="1.0"), musí načí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 pro vaše webové rozhraní API nakonfigurovaná autorita v2.0. - Když vaše webová aplikace nebo API ověřuje token v2.0 (
verclaim ="2.0"), musí načí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 pro vaše webové API nakonfigurovaná 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ěřte vydavatele
OpenID Connect Core říká: „Identifikátor vydavatele [...] MUSÍ přesně odpovídat hodnotě claimu iss (issuer).“ Pro aplikace, které používají koncový bod metadat specifický 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 rozhraní vrátí hodnotu vydavatele https://login.microsoftonline.com/{tenantid}/v2.0. 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 aplikace očekávala, že claim issuer v tokenu bude přesně odpovídat hodnotě issuer z metadat, měla by v metadatech issuer nahradit hodnotu
{tenantid}ID tenanta, na který aktuální požadavek cílí, a poté ověřit 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 vydavatele, například
https://login.microsoftonline.com/{tenantid}/v2.0, lze použít s jakýmkoli odpovídajícím vydavatelem tokenu. - Klíče, které mají hodnotu issuer, například
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0, by se měly používat pouze pro přesnou shodu.
Koncový bod klíčů Microsoft Entra nezávislý na tenantovi (https://login.microsoftonline.com/common/discovery/v2.0/keys) vrací dokument ve tvaru:
{ "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 vydavatele, například
Aplikace, které používají deklaraci identity tenanta Microsoft Entra (
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 se vystavitel a ID tenanta shodují.
Použití metadat nezávislých na tenantovi je efektivnější pro aplikace, které přijímají tokeny z mnoha tenantů.
Poznámka:
U metadat Microsoft Entra nezávislých na tenantovi by se claimy měly interpretovat v rámci tenanta, stejně jako se ve standardu OpenID Connect claimy interpretují v rámci vystavitele. To znamená, že {"sub":"ABC123","iss":"https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0","tid":"aaaabbbb-0000-cccc-1111-dddd2222eeee"} a {"sub":"ABC123","iss":"https://login.microsoftonline.com/bbbbcccc-1111-dddd-2222-eeee3333ffff/v2.0","tid":"bbbbcccc-1111-dddd-2222-eeee3333ffff"} označují různé uživatele, i když je sub stejný, protože claimy, jako je sub, se interpretují v kontextu vystavitele/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
Návod
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 použijte claim kid. Přestože tokeny v1.0 obsahují claimy x5t i kid, tokeny v2.0 obsahují pouze claim kid.
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í, přidejte parametr dotazu appid, 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 o hodnotě https://login.microsoftonline.com/{tenant}/discovery/keys?appid=00001111-aaaa-2222-bbbb-3333cccc4444.
Ověřit vydavatele
Webové aplikace ověřující tokeny ID a webová API ověřující přístupové tokeny musí ověřit vydavatele tokenu (deklarace iss) vůči:
- vydavatel dostupný v dokumentu metadat OpenID Connect souvisejícím s konfigurací aplikace (autorita). Dokument metadat, který se má ověřit, závisí na:
- verze tokenu
- účty podporované vaší aplikací.
- ID tenanta (
tiddeklarace identity) tokenu, - vydavatel podpisového klíče.
Aplikace s jedním tenantem
OpenID Connect Core uvádí: „Identifikátor vystavitele [...] musí přesně odpovídat hodnotě claimu iss (issuer).“ Pro aplikace, které používají koncový bod metadat specifický pro tenanta, například https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration nebo 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(consumers je přezdívka tenanta 9188040d-6c67-4c5b-b112-36a304b66dad)
Víceklientských aplikací
Microsoft Entra ID také podporuje víceklientské 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 na adresách https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration a https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration v uvedeném pořadí. Tyto endpointy vracejí hodnotu vydavatele, což je šablona s 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ěřte vystavitele podpisového klíče
- Místo toho, aby aplikace očekávala, že nárok vystavitele v tokenu bude přesně odpovídat hodnotě vystavitele v metadatech, měla by v metadatech vystavitele nahradit hodnotu
{tenantid}ID tenanta, na který je aktuální požadavek cílen, a poté ověřit přesnou shodu s nárokemtidv tokenu. - Ověřte, že claim
tidje identifikátor GUID a claimissmá tvarhttps://login.microsoftonline.com/{tid}/v2.0, kde{tid}je přesná hodnota claimutid. 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. - Použijte atribut identity
tid, když vyhledáváte data přidružená k subjektu atributu identity. Jinými slovy, atributtidmusí být součástí klíče používaného pro přístup k datům uživatele.
Ověřte vydavatele podpisového klíče
Aplikace využívající metadata verze v2.0 nezávislá na tenantovi musí ověřit vydavatele klíče pro podepisování.
Dokument s klíči a vydavatel 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 common, **organizations a consumers.
Dokumenty keys zpřístupněné službou Azure AD v2.0 obsahují u každého klíče vydavatele, který tento podpisový klíč používá. Například koncový bod klíče „common“ https://login.microsoftonline.com/common/discovery/v2.0/keys, který je nezávislý na tenantovi, vrací dokument podobný tomuto:
{
"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 issuer s identifikátorem GUID, například
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0, by se měly používat pouze tehdy, když se deklaraceissv tokenu s touto hodnotou přesně shoduje. - Klíče, které mají šablonovanou hodnotu vystavitele, například
https://login.microsoftonline.com/{tenantid}/v2.0, by se měly použít pouze tehdy, pokud claimissv tokenu odpovídá této hodnotě po nahrazení zástupného symbolu{tenantid}hodnotou claimutidz tokenu.
Použití metadat nezávislých na tenantovi je efektivnější pro aplikace, které přijímají tokeny z mnoha tenantů.
Poznámka:
U metadat Microsoft Entra nezávislých na tenantovi by se claimy měly vyhodnocovat v rámci tenanta, stejně jako se ve standardním OpenID Connect claimy vyhodnocují v rámci vydavatele. To znamená, že {"sub":"ABC123","iss":"https://login.microsoftonline.com/{example-tenant-id}/v2.0","tid":"{example-tenant-id}"} a {"sub":"ABC123","iss":"https://login.microsoftonline.com/{another-tenand-id}/v2.0","tid":"{another-tenant-id}"} popisují různé uživatele, i když je sub stejné, protože claimy, jako je sub, se interpretují v kontextu vystavitele nebo tenanta.
Rekapitulace
Zde je pseudokód, který shrnuje, jak ověřit vydavatele a vydavatele podpisového klíče:
- Načtení klíčů z nakonfigurované adresy URL metadat
- Zkontrolujte, zda je token podepsán jedním z publikovaných klíčů, jinak selže
- Určete klíč v metadatech na základě hlavičky `kid`. Zkontrolujte vlastnost „issuer“ připojenou ke 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;