Microsoft identity platform přístupových tokenů

Přístupové tokeny umožňují klientům bezpečně volat chráněná webová rozhraní API a webová rozhraní API je používají k ověřování a autorizaci. Podle specifikace OAuth jsou přístupové tokeny neprůhledné řetězce bez nastaveného formátu – někteří zprostředkovatelé identity používají identifikátory GUID, jiné šifrované objekty blob. V Microsoft identity platform používá různé formáty přístupových tokenů v závislosti na konfiguraci rozhraní API, které token přijímá. Vlastní rozhraní API registrovaná vývojáři v Microsoft identity platform si mohou vybrat ze dvou různých formátů webových tokenů JSON (JWT), které se nazývají "v1" a "v2", a rozhraní API vyvinutá Microsoftem, jako je Microsoft Graph nebo rozhraní API v Azure, mají další proprietární formáty tokenů. Tyto proprietární formáty můžou být šifrované tokeny, tokeny JWT nebo speciální tokeny ve formátu JWT, které se neověřují.

Klienti musí přístupové tokeny považovat za neprůhledné řetězce, protože obsah tokenu je určený pouze pro prostředek (rozhraní API). Pouze pro účely ověřování a ladění mohou vývojáři dekódovat JWT pomocí webu, jako je jwt.ms. Uvědomte si ale, že tokeny, které obdržíte pro rozhraní API Microsoftu, nemusí být vždy JWT a že je nemůžete vždy dekódovat.

Pokud chcete získat podrobnosti o tom, co je uvnitř přístupového tokenu, klienti by měli použít data odpovědi tokenu vrácená s přístupovým tokenem vašemu klientovi. Když klient požádá o přístupový token, Microsoft identity platform také metadata o přístupových tokenech pro spotřebu vaší aplikace. Mezi tyto informace patří doba vypršení platnosti přístupového tokenu a rozsahy, pro které je platný. Tato data umožňují vaší aplikaci inteligentní ukládání přístupových tokenů do mezipaměti bez nutnosti parsovat samotný přístupový token.

V následujících částech se dozvíte, jak může rozhraní API 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 to napsané, se vztahuje pouze na tokeny vydané pro rozhraní API, která jste zaregistrovali. Nevztahuje se na tokeny vydávané pro rozhraní API vlastněná Microsoftem, ani tyto tokeny nelze použít k ověření, jak bude Microsoft identity platform vydávat tokeny pro rozhraní API, které vytvoříte.

Formáty a vlastnictví tokenů

v1.0 a v2.0

V systému jsou k dispozici dvě verze Microsoft identity platform přístupových tokenů: v1.0 a v2.0. Tyto verze řídí, jaké deklarace identity jsou v tokenu, a zajišťují, že webové rozhraní API může řídit, jak jejich tokeny vypadají. Webová rozhraní API mají jedno z těchto rozhraní vybrané jako výchozí během registrace – v1.0 pro aplikace pouze pro Azure AD a v2.0 pro aplikace, které podporují účty uživatelů. To je možné řídit v aplikacích pomocí nastavení v manifestu aplikace , kde a vyústují accessTokenAcceptedVersion null v 1 tokeny v1.0 a výsledkem jsou 2 tokeny v2.0.

Jaká aplikace je token "pro"?

Žádost o přístupový token se účastní dvě strany: klient, který token požaduje, a prostředek (rozhraní API), který při volání rozhraní API přijímá token. Deklarace aud identity v tokenu označuje prostředek, pro který je token určený (jeho cílová skupina). Klienti token používají, ale neměli by mu rozumět ani se ho pokoušet parsovat. Prostředky token přijímají.

Tento Microsoft identity platform podporuje vystavování jakékoli verze tokenu z libovolného koncového bodu verze – tyto verze nejsou v souvislosti. To je důvod, proč nastavení prostředku znamená, že klient, který volá koncový bod v1.0 pro získání tokenu pro toto rozhraní API, obdrží přístupový accessTokenAcceptedVersion 2 token v2.0. Prostředky vždy vlastní své tokeny (ty, které mají deklaraci identity) a jsou jedinými aplikacemi, aud které mohou změnit podrobnosti o tokenu. To je důvod, proč změna volitelných deklarací identity přístupového tokenu pro vašeho klienta nezmění přístupový token přijatý při vyžádání tokenu pro , který vlastní prostředek Graph user.read Microsoftu.

Ukázkové tokeny

Tokeny v1.0 a v2.0 vypadají podobně a obsahují mnoho stejných deklarací identity. Tady najdete příklad každého z nich. Tyto příklady tokenů všakneověřují , protože klíče se před publikováním obměnaly a osobní údaje z nich byly odebrány.

v1.0

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd

Zobrazte tento token v1.0 v JWT.ms.

v2.0

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt

Tento token v2.0 si můžete prohlédnout v JWT.ms.

Deklarace identity v přístupových tokenech

Jwt (webové tokeny JSON) jsou rozdělené na tři části:

  • Hlavička – Poskytuje informace o tom, jak token ověřit, včetně informací o typu tokenu a způsobu jeho podepsání.
  • Datová část – obsahuje všechna důležitá data o uživateli nebo aplikaci, která se pokouší volat vaši službu.
  • Signature (Podpis) – nezpracovaná materiál, který se používá k ověření tokenu.

Každá část je oddělená tečkou ( ) a . samostatně s kódováním Base64.

Deklarace identity jsou k dispozici pouze v případě, že existuje hodnota, která ji vyplní. Vaše aplikace by neměla být závislá na přítomné deklaraci identity. Mezi příklady patří (ne každý tenant vyžaduje vypršení platnosti hesel) a (toky přihlašovacích údajů klienta jsou jménem aplikací, které pwd_exp family_name nemají názvy). Deklarace identity používané k ověření přístupového tokenu budou vždy k dispozici.

Některé deklarace identity pomáhají službě Azure AD zabezpečit tokeny v případě jejich opětovného použití. Ty jsou v popisu označené jako neprůhledné a nejsou pro veřejné využití. Tyto deklarace identity se dají nebo nemusí v tokenu objevit a nové se dají přidat bez předchozího upozornění.

Deklarace identity hlaviček

Deklarovat Formát Description
typ String – always "JWT" Označuje, že token je JWT.
alg Řetězec Označuje algoritmus použitý k podepsání tokenu, například RS256.
kid Řetězec Určuje kryptografický otisk veřejného klíče, který lze použít k ověření podpisu tohoto tokenu. Vysílá se v přístupových tokenech v1.0 i v2.0.
x5t Řetězec Funguje stejně (v use a value) jako kid . x5t je starší verze deklarace identity vygenerovaná pouze v přístupových tokenech verze 1.0 pro účely kompatibility.

Deklarace identity datové části

Deklarovat Formát Description
aud Řetězec, identifikátor URI nebo identifikátor GUID ID aplikace Identifikuje zamýšleného příjemce tokenu – jeho cílovou skupinu. Vaše rozhraní API musí tuto hodnotu ověřit a odmítnout token, pokud se hodnota neshoduje. V tokenech verze 2.0 se vždy jedná o ID klienta rozhraní API, zatímco v tokenech verze 1.0 to může být ID klienta nebo identifikátor URI prostředku použitý v požadavku v závislosti na tom, jak klient požádal o token.
iss Řetězec, identifikátor URI služby STS Identifikuje službu tokenů zabezpečení (STS), která vytvoří a vrátí token, a tenanta Azure AD, ve kterém byl uživatel ověřen. Pokud je vystavený token tokenem v2.0 (viz deklarace identity), identifikátor ver URI skončí na /v2.0 . Identifikátor GUID, který označuje, že uživatel je uživatelským uživatelem z účet Microsoft je 9188040d-6c67-4c5b-b112-36a304b66dad . Vaše aplikace může pomocí části identifikátoru GUID deklarace identity omezit sadu tenantů, které se k aplikaci mohou přihlásit, pokud je to možné.
idp Řetězec, obvykle identifikátor URI služby STS Zaznamenává zprostředkovatele identity, který ověřil subjekt tokenu. Tato hodnota je stejná jako hodnota deklarace identity Vystavitel, pokud například uživatelský účet není ve stejném tenantovi jako vystavitel – hosté. Pokud deklarace identity není k dispozici, znamená to, že je iss možné místo toho použít hodnotu . U osobních účtů používaných v kontextu organizace (například osobní účet pozvaný do tenanta Azure AD) může být deklarace identity "live.com" nebo identifikátor URI služby STS obsahující účet Microsoft idp tenanta 9188040d-6c67-4c5b-b112-36a304b66dad služby .
iat int, časové systém UNIX razítko Vystavený v označuje, kdy došlo k ověření tohoto tokenu.
nbf int, časové systém UNIX razítko Deklarace "nbf" (nikoli dříve) určuje čas, před kterým nesmí být jwt přijat ke zpracování.
exp int, časové systém UNIX razítko Deklarace "exp" (čas vypršení platnosti) určuje čas vypršení platnosti, ve kterém nesmí být jwT přijat ke zpracování. Je důležité si uvědomit, že prostředek může token před tímto časem odmítnout, například když se vyžaduje změna ověřování nebo bylo zjištěno odvolání tokenu.
aio Neprůhledný řetězec Interní deklarace identity používaná službou Azure AD k zaznamenání dat pro opakované použití tokenů. Prostředky by tuto deklaraci identity neměly používat.
acr Řetězec, "0" nebo "1" K dispozici pouze v tokenech v1.0. Deklarace identity "Třída kontextu ověřování". Hodnota "0" značí, že ověřování koncového uživatele nesplňuje požadavky iso/IEC 29115.
amr Pole JSON řetězců K dispozici pouze v tokenech v 1.0. Určuje způsob ověření předmětu tokenu. Další podrobnosti najdete v části deklarace identity AMR .
appid Řetězec, identifikátor GUID K dispozici pouze v tokenech v 1.0. ID aplikace klienta, který používá token. Aplikace může fungovat samostatně nebo jménem uživatele. ID aplikace obvykle představuje objekt aplikace, ale může také představovat instanční objekt služby ve službě Azure AD.
azp Řetězec, identifikátor GUID Je k dispozici pouze v tokenech verze 2.0, což je náhrada za appid . ID aplikace klienta, který používá token. Aplikace může fungovat samostatně nebo jménem uživatele. ID aplikace obvykle představuje objekt aplikace, ale může také představovat instanční objekt služby ve službě Azure AD.
appidacr "0", "1" nebo "2" K dispozici pouze v tokenech v 1.0. Označuje způsob ověření klienta. U veřejného klienta je hodnota "0". Pokud se použije ID klienta a tajný klíč klienta, hodnota je 1. Pokud byl klientský certifikát použit k ověření, hodnota je "2".
azpacr "0", "1" nebo "2" Je k dispozici pouze v tokenech verze 2.0, což je náhrada za appidacr . Označuje způsob ověření klienta. U veřejného klienta je hodnota "0". Pokud se použije ID klienta a tajný klíč klienta, hodnota je 1. Pokud byl klientský certifikát použit k ověření, hodnota je "2".
preferred_username Řetězec Primární uživatelské jméno, které představuje uživatele. Může to být e-mailová adresa, telefonní číslo nebo obecné uživatelské jméno bez zadaného formátu. Jeho hodnota je proměnlivá a může se v průběhu času měnit. Protože je proměnlivá, nesmí se tato hodnota použít k rozhodování o autorizaci. Dá se použít k zadání tipů k uživatelskému jménu, ale k uživatelskému rozhraní čitelnému uživatelem. profileAby bylo možné získat tuto deklaraci, je vyžadován rozsah. K dispozici pouze v tokenech verze 2.0.
name Řetězec Poskytuje uživatelsky čitelné hodnoty, které identifikují předmět tokenu. Hodnota není zaručena jako jedinečná, je proměnlivá a je navržena tak, aby se používala pouze pro účely zobrazení. profileAby bylo možné získat tuto deklaraci, je vyžadován rozsah.
scp Řetězec, seznam oborů oddělených mezerami Sada oborů vystavené vaší aplikací, pro které klientská aplikace požádala o souhlas. Vaše aplikace by měla ověřit, že tyto obory jsou platné, které jsou vystavené vaší aplikací, a učinit rozhodnutí o autorizaci na základě hodnoty těchto oborů. Je zahrnutá jenom pro tokeny uživatelů.
roles Pole řetězců, seznam oprávnění Sada oprávnění vystavená vaší aplikací, ke které žádající aplikace nebo uživatel udělil oprávnění k volání. Pro aplikační tokenyse používá v rámci toku přihlašovacích údajů klienta (v 1.0, v 2.0) místo uživatelských oborů. Pro tokeny uživatele se naplní role, ke kterým se uživatel přiřadil v cílové aplikaci.
wids Pole RoleTemplateID identifikátorů GUID Označuje role v rámci tenanta přiřazené tomuto uživateli z části rolí, které jsou k dispozici v předdefinovaných rolích služby Azure AD. Tato deklarace identity je nakonfigurovaná na základě jednotlivých aplikací prostřednictvím groupMembershipClaims vlastnosti manifestu aplikace. Nastaví se na All nebo DirectoryRole se vyžaduje. Nemusí být k dispozici v tokenech získaných prostřednictvím implicitního toku, protože se týkají délky tokenu.
groups Pole JSON identifikátorů GUID Poskytuje ID objektů, které představují členství ve skupině daného subjektu. Tyto hodnoty jsou jedinečné (viz ID objektu) a lze je bezpečně použít ke správě přístupu, jako je vynucení autorizace pro přístup k prostředku. Skupiny zahrnuté v deklaraci skupin jsou nakonfigurovány na základě jednotlivých aplikací prostřednictvím groupMembershipClaims vlastnosti manifestu aplikace. hodnota null bude vyloučit všechny skupiny, hodnota "Security group" bude zahrnovat pouze členství ve skupině zabezpečení služby Active Directory a hodnota "vše" bude zahrnovat skupiny zabezpečení a distribuční seznamy Microsoft 365.

hasgroupsPodrobnosti o použití groups deklarace s implicitním grantem naleznete níže v deklaraci identity.
u jiných toků platí, že pokud počet skupin, ve kterých se uživatel nachází, se nachází v rámci limitu (150 pro SAML, 200 pro JWT), pak se nadlimitní deklarace identity přidá do zdrojů deklarací, které ukazují na Microsoft Graph koncový bod, který obsahuje seznam skupin pro uživatele.
hasgroups Logická hodnota Pokud je k dispozici, znamená to, true že uživatel má alespoň jednu skupinu. Používá se místo groups deklarace identity pro JWTs v implicitních tocích toků, pokud by deklarace identity celé skupiny rozšířila fragment identifikátoru URI za omezení délky adresy URL (aktuálně 6 nebo více skupin). určuje, že klient musí použít rozhraní Microsoft Graph API k určení skupin uživatelů ( https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects ).
groups:src1 Objekt JSON Pro žádosti o tokeny, které nejsou omezené na délku (viz hasgroups výše), ale u tokenu je ještě moc velká, se zobrazí odkaz na seznam úplných skupin pro uživatele. Pro JWTs jako distribuovanou deklaraci protokolu SAML jako nové deklarace místo groups deklarace identity.

Ukázková hodnota JWT:
"groups":"src1"
"_claim_sources: "src1" : { "endpoint" : "https://graph.microsoft.com/v1.0/users/{userID}/getMemberObjects" }
sub Řetězec Objekt zabezpečení, o kterém token vyhodnotí informace, jako je například uživatel aplikace Tato hodnota je neměnná a nelze ji znovu přiřadit ani použít znovu. Dá se použít k bezpečnému provádění kontrol autorizace, například když se token používá pro přístup k prostředku a dá se použít jako klíč v databázových tabulkách. Vzhledem k tomu, že předmět je vždy přítomen v tokenech, které služba Azure AD vystavuje, doporučujeme použít tuto hodnotu v systému autorizace pro obecné účely. Subjekt je však párový identifikátor, který je jedinečný pro konkrétní ID aplikace. Proto pokud se jeden uživatel přihlásí ke dvěma různým aplikacím pomocí dvou různých ID klientů, obdrží tyto aplikace dvě různé hodnoty pro deklaraci předmětu. To může nebo nemusí být žádoucí v závislosti na vaší architektuře a požadavcích na ochranu osobních údajů. Viz také oid deklarace identity (která zůstává v aplikacích v rámci tenanta stejná).
oid Řetězec, identifikátor GUID Neproměnlivý identifikátor "objektu zabezpečení" žádosti – uživatel nebo instanční objekt, jehož identita byla ověřena. V tokenech ID a v tokenech aplikací a uživatelů se jedná o ID objektu uživatele. V tokenech pouze pro aplikaci je toto ID objektu volajícího objektu služby. Dá se taky použít k bezpečnému provádění kontrol autorizace a jako klíče v databázových tabulkách. Toto ID jednoznačně identifikuje objekt zabezpečení napříč aplikacemi – dvě různé aplikace přihlášené ke stejnému uživateli získají stejnou hodnotu v oid deklaraci identity. Proto oid lze použít při vytváření dotazů do Microsoft Online služby, jako je například Microsoft Graph. Microsoft Graph bude toto ID vracet jako id vlastnost pro daný uživatelský účet. Vzhledem k tomu, že umožňuje, aby oid více aplikací koreluje objekty zabezpečení, profile je obor požadován pro uživatele, aby mohl tuto deklaraci identity získat. Všimněte si, že pokud jeden uživatel existuje ve více klientech, bude uživatel v každém tenantovi obsahovat jiné ID objektu – považují se za jiné účty, i když se uživatel do každého účtu přihlašuje pomocí stejných přihlašovacích údajů.
tid Řetězec, identifikátor GUID Představuje tenanta, ke kterému se uživatel přihlašuje. V případě pracovních a školních účtů je identifikátor GUID neměnné ID klienta organizace, ke které se uživatel přihlašuje. pro přihlášení do tenanta osobního účet Microsoft (služby, jako je Xbox, Teams pro život nebo Outlook), je hodnota 9188040d-6c67-4c5b-b112-36a304b66dad . Pro příjem této deklarace musí vaše aplikace požádat o profile obor.
unique_name Řetězec K dispozici pouze v tokenech v 1.0. Poskytuje lidsky čitelnou hodnotu, která identifikuje subjekt tokenu. Tato hodnota není zaručena jako jedinečná v rámci tenanta a měla by být použita pouze pro účely zobrazení.
uti Neprůhledný řetězec Interní deklarace identity, kterou Azure používá k opětovnému ověření tokenů. Prostředky by tuto deklaraci neměli používat.
rh Neprůhledný řetězec Interní deklarace identity, kterou Azure používá k opětovnému ověření tokenů. Prostředky by neměly tuto deklaraci identity používat.
ver Řetězec, 1.0 nebo 2.0 Určuje verzi přístupového tokenu.

Deklarace identity nadage (nadage) skupin

Aby se zajistilo, že velikost tokenu nepřekročí omezení velikosti hlavičky HTTP, Azure AD omezuje počet ID objektů, které zahrnuje do deklarace identity skupin. Pokud je uživatel členem více skupin, než je limit nad limitu nad limitu (150 pro tokeny SAML, 200 pro tokeny JWT a pouze 6, pokud je vystaven prostřednictvím implicitního toku), Azure AD nevysílá deklaraci identity skupin v tokenu. Místo toho obsahuje deklaraci identity nadávku, která aplikaci indikuje, že se má rozhraní API služby Microsoft Graph dotazovat na načtení členství uživatele ve skupině.

{
  ...
  "_claim_names": {
   "groups": "src1"
    },
    {
  "_claim_sources": {
    "src1": {
        "endpoint":"[Url to get this user's group membership from]"
        }
       }
     }
  ...
}

K otestování scénářů nad využití můžete použít soubor , který najdete ve složce Skripty BulkCreateGroups.ps1 pro vytváření aplikací.

Základní deklarace identity verze 1.0

Následující deklarace identity budou zahrnuty v tokenech v1.0, pokud jsou k dispozici, ale nejsou zahrnuty v tokenech v2.0 ve výchozím nastavení. Pokud používáte v2.0 a potřebujete jednu z těchto deklarací identity, požádejte o ně pomocí volitelných deklarací identity.

Deklarovat Formát Description
ipaddr Řetězec IP adresa, ze které se uživatel ověřil.
onprem_sid Řetězec ve formátu SID V případech, kdy má uživatel místní ověřování, tato deklarace identity poskytne svůj SID. Můžete použít k onprem_sid autorizaci ve starších verzích aplikací.
pwd_exp int, časové systém UNIX razítko Určuje, kdy vyprší platnost hesla uživatele.
pwd_url Řetězec Adresa URL, na kterou je možné odeslat uživatele, aby si mohli resetovat heslo.
in_corp boolean Signalizuje, jestli se klient přihlašuje z podnikové sítě. Pokud ne, deklarace identity se nezahrne.
nickname Řetězec Další jméno uživatele oddělené od jména nebo příjmení.
family_name Řetězec Poskytuje příjmení, příjmení nebo příjmení uživatele, jak je definováno v objektu uživatele.
given_name Řetězec Poskytuje jméno nebo jméno uživatele nastavené pro objekt uživatele.
upn Řetězec Uživatelské jméno uživatele. Může to být telefonní číslo, e-mailová adresa nebo neformátovaný řetězec. Měl by se používat jenom pro účely zobrazení a poskytování tipů pro uživatelské jméno ve scénářích opětovného ověření.

Deklarace amr identity

Identity Od Microsoftu se mohou ověřovat různými způsoby, což může být relevantní pro vaši aplikaci. Deklarace identity je pole, které může obsahovat více položek, například , pro ověřování, které používalo heslo amr ["mfa", "rsa", "pwd"] i Authenticator aplikace.

Hodnota Popis
pwd Ověřování heslem, buď heslo uživatele Microsoftu, nebo tajný kód klienta aplikace.
rsa Ověřování bylo založené na ověření klíče RSA, například u Microsoft Authenticator aplikace. To zahrnuje, jestli ověřování provedl certifikát X509 podepsaný svým držitelem JWT.
otp Jedno heslo pomocí e-mailu nebo textové zprávy.
fed Použili jsme kontrolní výraz federovaného ověřování (například JWT nebo SAML).
wia Windows Integrované ověřování
mfa Bylo použito vícefaktorové ověřování. Pokud je k dispozici, budou zahrnuty i další metody ověřování.
ngcmfa Odpovídá , mfa který se používá ke zřizování určitých pokročilých typů přihlašovacích údajů.
wiaormfa Uživatel použil k Windows přihlašovací údaje MFA.
none Nebylo provedeno žádné ověření.

Doba života přístupového tokenu

Výchozí doba života přístupového tokenu se liší v závislosti na klientské aplikaci, která token požaduje. Například klienti s podporou průběžného vyhodnocování přístupu (CAE), kteří vyjednají relace s podporou CAE, uvidí dlouhou životnost tokenu (až 28 hodin). Po vypršení platnosti přístupového tokenu musí klient použít obnovovací token, aby (obvykle bezobslužně) získal nový obnovovací token a přístupový token.

Dobu života přístupového tokenu můžete upravit tak, abyste mohli řídit, jak často klientská aplikace vyprší platnost relace aplikace a jak často vyžaduje, aby se uživatel znovu ověřil (bezobslužně nebo interaktivně). Další informace najdete v tématu Konfigurovatelné životnosti tokenů.

Ověřování tokenů

Tokeny by neměly ověřovat všechny aplikace. Pouze v určitých scénářích by aplikace měly token ověřit:

  • Webová rozhraní API musí ověřovat přístupové tokeny odeslané klientem. Musí přijímat pouze tokeny obsahující aud deklaraci identity.
  • Důvěrné webové aplikace, jako je ASP.NET Core, musí před povolením přístupu k datům uživatele nebo vytvořením relace ověřit tokeny ID, které jim uživatel poslal v prohlížeči v hybridním toku.

Pokud žádný z výše uvedených scénářů neplatí, vaše aplikace nebude mít výhodu v ověřování tokenu a v případě rozhodnutí na základě platnosti tokenu může být ohroženo zabezpečením a spolehlivostí. Veřejné klienty, jako jsou nativní aplikace nebo spa, nevyužití ověřování tokenů – aplikace komunikuje přímo s dp. Ochrana SSL zajišťuje platnost tokenů.

Rozhraní API a webové aplikace musí ověřovat pouze tokeny, které mají deklaraci identity, která odpovídá jejich aplikaci; jiné prostředky aud mohou mít vlastní ověřovací pravidla tokenu. Například tokeny pro Microsoft Graph se neověřují podle těchto pravidel kvůli jejich proprietárnímu formátu. Ověřování a přijímání tokenů chystajících se pro jiný prostředek je příkladem zmatených problémů.

Pokud vaše aplikace potřebuje ověřit id_token nebo access_token podle výše uvedeného příkladu, měla by aplikace nejprve ověřit podpis a vystavitele tokenu proti hodnotám v dokumentu zjišťování OpenID. Například verze dokumentu nezávislá na tenantovi se nachází v https://login.microsoftonline.com/common/.well-known/openid-configuration .

Pro ty, kdo chtějí porozumět základnímu procesu, jsou k dispozici následující informace. Middleware Azure AD má integrované funkce pro ověřování přístupových tokenů a můžete si projít naše ukázky a najít ho v jazyce podle vašeho výběru. K dispozici je také několik open source knihoven třetích stran pro ověřování JWT – pro téměř každou platformu a jazyk existuje alespoň jedna možnost. Další informace o knihovnách ověřování Azure AD a ukázkách kódu najdete v knihovnách ověřování.

Ověření podpisu

JWT obsahuje tři segmenty, které jsou odděleny . znakem . První segment se označuje jako hlavička, druhý jako text a třetí jako podpis. Segment podpisů lze použít k ověření pravosti tokenu, aby jej vaše aplikace důvěřoval.

Tokeny vydané službou Azure AD jsou podepsané standardními algoritmy asymetrického šifrování, 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 identity označuje algoritmus, který byl použit k podepsání tokenu, zatímco deklarace identity označuje konkrétní veřejný klíč, který byl použit alg kid k ověření tokenu.

V libovolném časovém okamžiku může Azure AD podepsat id_token pomocí některé z určitých párů veřejného a privátního klíče. Azure AD pravidelně obměnuje možnou sadu klíčů, takže by vaše aplikace měla být napsána tak, aby tyto změny klíčů zvládla automaticky. Přiměřená frekvence kontroly aktualizací veřejných klíčů používaných službou Azure AD je každých 24 hodin.

Data podpisového klíče potřebná k ověření podpisu můžete získat pomocí OpenID Připojení metadat, který se nachází v:

https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration

Tip

Vyzkoušejte si tuto adresu URL v prohlížeči!

Tento dokument metadat:

  • Je objekt JSON obsahující několik užitečných informací, například umístění různých koncových bodů požadovaných pro ověřování OpenID Připojení ověřování.
  • Zahrnuje , který poskytuje umístění sady veřejných klíčů, které odpovídají privátním klíčům použitým jwks_uri k podepsání tokenů. Soubor JSON Web Key (JWK) umístěný v obsahuje všechny informace o veřejném klíči, které se používají v jwks_uri tomto konkrétním okamžiku v čase. Formát JWK je popsaný v dokumentu RFC 7517. Vaše aplikace může použít 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í kid 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í kid tokenu doporučujeme použít deklaraci identity. Přestože tokeny v1.0 obsahují deklarace identity i x5t kid , tokeny v2.0 obsahují pouze kid deklaraci identity.

Ověřování podpisů je nad rámec tohoto dokumentu – v případě potřeby je k dispozici mnoho open source knihoven. Pro tento Microsoft identity platform ale jedno rozšíření podepisování tokenů pro standardy – vlastní podpisové klíče.

Pokud má vaše aplikace vlastní podpisové klíče v důsledku použití funkce mapování deklarací identity, musíte připojit parametr dotazu obsahující ID aplikace, abyste získali odkaz na informace o podpisových klíčích vaší aplikace, které by se měly použít appid k jwks_uri ověření. Příklad: https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e obsahuje jwks_uri hodnotu https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e .

Autorizace na základě deklarací identity

Obchodní logika vaší aplikace bude diktovat tento krok, některé běžné autorizační metody jsou uvedeny níže.

  • Použijte aud deklaraci identity, abyste zajistili, že uživatel má zavolat aplikaci. Pokud identifikátor prostředku není v aud deklaraci identity, odmítněte ho.
  • Pomocí scp deklarace identity ověříte, že uživatel udělil oprávnění volající aplikace pro volání vašeho rozhraní API.
  • Pomocí roles deklarací a wids ověříte, že uživatel má oprávnění volat vaše rozhraní API. Správce může například mít oprávnění k zápisu do vašeho rozhraní API, ale ne pro normálního uživatele.
  • Zajistěte, aby volající klient povolil volání rozhraní API pomocí appid deklarace identity.
  • Ověřte, že tid odpovídá klientovi, který má povolené volání rozhraní API.
  • Pomocí amr deklarace identity ověříte, že uživatel provedl MFA. Tato podmínka by se měla vyhovět pomocí podmíněného přístupu.
  • Pokud jste si vyžádali roles groups deklarace identity nebo v přístupovém tokenu, ověřte, jestli je uživatel ve skupině, která tuto akci povoluje.
    • pro tokeny načtené pomocí implicitního toku bude pravděpodobně nutné zadat dotaz na Microsoft Graph pro tato data, protože je často příliš velká, aby se vešla do tokenu.

Tokeny uživatelů a aplikací

Vaše aplikace může obdržet tokeny pro uživatele (obvykle se jedná o tento tok, který je popsán), nebo přímo z aplikace (prostřednictvím toku přihlašovacích údajů klienta). Tyto tokeny pouze pro aplikace označují, že toto volání přichází z aplikace a nemá uživatele, který ho zavedl. Tyto tokeny jsou zpracovávány hlavně stejně:

  • Pomocí roles zobrazíte oprávnění udělená předmětu tokenu.
  • Použijte oid nebo sub k ověření, zda je volající objekt služby očekáván.

Pokud vaše aplikace potřebuje rozlišovat přístupové tokeny jenom pro aplikace a přístupové tokeny pro uživatele, použijte idtyp volitelnou deklaraci identity. Když idtyp do pole přidáte deklaraci identity accessToken a zkontrolujete hodnotu app , můžete zjistit přístupové tokeny jenom pro aplikaci. Tokeny ID a přístupové tokeny pro uživatele nebudou obsahovat idtyp deklaraci identity.

Odvolání tokenu

Aktualizace tokenů se u různých důvodů může odhlásit nebo odvolat kdykoli. Patří do dvou hlavních kategorií: vypršení časových limitů a odvolaných certifikátů.

Vypršení časového limitu tokenů

Pomocí Konfigurace životnosti tokenůmůžete změnit životnost tokenů aktualizace. Je normální a očekává se, že některé tokeny mají jít bez použití (například uživatel neotevře aplikaci po dobu 3 měsíců), a proto vyprší. V aplikacích dojde k situacím, kdy přihlašovací server odmítne obnovovací token z důvodu jeho stáří.

  • MaxInactiveTime: Pokud se obnovovací token nepoužil v čase, který určí MaxInactiveTime, obnovovací token už nebude platný.
  • MaxSessionAge: Pokud jsou MaxAgeSessionMultiFactor nebo MaxAgeSessionSingleFactor nastavené na jinou hodnotu než výchozí (před odvoláním), pak se opětovné ověření bude vyžadovat po uplynutí doby nastavené v MaxAgeSession *.
  • Příklady:
    • Tenant má MaxInactiveTime po dobu pěti dnů a uživatel přešel na dovolenou za týden, takže Azure AD neviděl od uživatele novou žádost o token během 7 dnů. Když si uživatel příště požádá o nový token, uvidí svůj obnovovací token, který pak musí znovu zadat přihlašovací údaje.
    • Citlivá aplikace má MaxAgeSessionSingleFactor jeden den. Pokud se uživatel přihlásí v pondělí a v úterý (po 25 hodinách uplynul), bude se muset znovu ověřit.

Odvolání

Aktualizační tokeny může server odvolat z důvodu změny přihlašovacích údajů, nebo v důsledku použití nebo akce správce. Aktualizovat tokeny spadají do dvou tříd – těch vydaných důvěrným klientům (sloupec nejvíce vpravo) a těch vydaných pro veřejné klienty (všechny ostatní sloupce).

Změnit Soubor cookie založený na hesle Token založený na hesle Soubory cookie nezaložené na heslech Token založený na jiných heslech Důvěrný token klienta
Platnost hesla vyprší Zůstane aktivní Zůstane aktivní Zůstane aktivní Zůstane aktivní Zůstane aktivní
Heslo změnilo uživatel. Odvoláno Odvoláno Zůstane aktivní Zůstane aktivní Zůstane aktivní
Uživatel provede SSPR Odvoláno Odvoláno Zůstane aktivní Zůstane aktivní Zůstane aktivní
Správce resetuje heslo Odvoláno Odvoláno Zůstane aktivní Zůstane aktivní Zůstane aktivní
Uživatel Odvolá své aktualizační tokeny prostřednictvím PowerShellu . Odvoláno Odvoláno Odvoláno Odvoláno Odvoláno
Správce odvolá všechny aktualizační tokeny pro uživatele prostřednictvím PowerShellu . Odvoláno Odvoláno Odvoláno Odvoláno Odvoláno
Jednotné odhlašování (v 1.0, v 2.0 ) na webu Odvoláno Zůstane aktivní Odvoláno Zůstane aktivní Zůstane aktivní

Založené na jiných heslách

Přihlášení bez hesla je jeden z nich, kdy uživatel nezadal heslo pro jeho získání. Příklady přihlášení pomocí hesla bez hesla zahrnují:

  • Použití vaší plochy s Windows Hello
  • FIDO2 klíč
  • SMS
  • Hlas
  • PIN

Další podrobnosti o primárních tokenech pro aktualizaci najdete v primárních tokenech aktualizace .

Další kroky