Přehled tokenů v Azure Active Directory B2C

Důležité

Od 1. května 2025 už nebude Azure AD B2C k dispozici k nákupu pro nové zákazníky. Další informace najdete v našich nejčastějších dotazech.

Azure Active Directory B2C (Azure AD B2C) generuje různé typy tokenů zabezpečení, protože zpracovává každý tok ověřování . Tento článek popisuje formát, charakteristiky zabezpečení a obsah každého typu tokenu.

Typy tokenů

Azure AD B2C podporuje protokoly OAuth 2.0 a OpenID Connect, které využívají tokeny pro ověřování a zabezpečený přístup k prostředkům. Všechny tokeny používané v Azure AD B2C jsou webové tokeny JSON (JWT), které obsahují prohlášení o informacích o nositeli a subjektu tokenu.

Ke komunikaci s Azure AD B2C se používají následující tokeny:

ID token – JWT obsahující nároky, které můžete použít k identifikaci uživatelů ve vaší aplikaci. Tento token se bezpečně odesílá v požadavcích HTTP pro komunikaci mezi dvěma komponentami stejné aplikace nebo služby. Můžete použít nároky v ID tokenu podle vlastního uvážení. Běžně se používají k zobrazení informací o účtu nebo k rozhodování o řízení přístupu v aplikaci. Tokeny ID vydané službou Azure AD B2C jsou podepsané, ale nejsou šifrované. Když vaše aplikace nebo rozhraní API obdrží token ID, musí ověřit podpis, aby bylo možné prokázat, že je token autentický. Vaše aplikace nebo rozhraní API musí také ověřit několik deklarací identity v tokenu, aby bylo možné prokázat, že je platná. V závislosti na požadavcích na scénáře se deklarace identity ověřené aplikací můžou lišit, ale vaše aplikace musí v každém scénáři provádět několik běžných ověření deklarací identity.
přístupový token – JWT obsahující informace, které můžete použít k identifikaci přiřazených oprávnění pro vaše rozhraní API. Přístupové tokeny jsou podepsané, ale nejsou šifrované. Přístupové tokeny slouží k poskytování přístupu k rozhraním API a serverům prostředků. Když vaše rozhraní API obdrží přístupový token, musí ověřit podpis, aby bylo možné prokázat, že je token autentický. Vaše rozhraní API také musí ověřit několik deklarací identity v tokenu, aby bylo možné prokázat, že je platné. V závislosti na požadavcích na scénáře se deklarace identity ověřené aplikací můžou lišit, ale vaše aplikace musí v každém scénáři provádět několik běžných ověření deklarací identity.
Obnovovací token – Obnovovací tokeny se používají k získání nových ID tokenů a přístupových tokenů v rámci toku OAuth 2.0. Poskytují vaší aplikaci dlouhodobý přístup k prostředkům jménem uživatelů bez nutnosti interakce s těmito uživateli. Obnovovací tokeny jsou neprůžné pro vaši aplikaci. Vydává je Azure AD B2C a dá se zkontrolovat a interpretovat pouze službou Azure AD B2C. Mají dlouhou životnost, ale vaše aplikace by neměla být psána s očekáváním, že obnovovací token vydrží určitou dobu. Obnovovací tokeny je možné kdykoliv zneplatnit z různých důvodů. Jediným způsobem, jak vaše aplikace zjistit, jestli je platný obnovovací token, je pokus o jeho uplatnění provedením žádosti o token do Azure AD B2C. Když vyměníte token pro obnovení za nový token, dostanete v odpovědi nový token pro obnovení. Uložte nový obnovovací token. Nahradí aktualizační token, který jste dříve použili v požadavku. Tato akce pomáhá zaručit, že obnovovací tokeny zůstanou platné co nejdéle. Jednostránkové aplikace využívající tok autorizačního kódu s využitím PKCE vždy mají životnost obnovovacího tokenu 24 hodin. Další informace o bezpečnostních dopadech obnovovacích tokenů v prohlížeči.

Koncové uzly

zaregistrovaná aplikace přijímá tokeny a komunikuje s Azure AD B2C odesláním požadavků do těchto koncových bodů:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Tokeny zabezpečení, které vaše aplikace přijímá z Azure AD B2C, můžou pocházet z koncových bodů /authorize nebo /token. Při získávání ID tokenů z:

/authorize koncový bod se provádí pomocí implicitního toku, který se často používá pro uživatele, kteří se přihlašuje k webovým aplikacím založeným na JavaScriptu. Pokud ale vaše aplikace používá MSAL.js 2.0 nebo novější, nepovolujte implicitní tok v registraci své aplikace, protože MSAL.js 2.0+ podporuje tok autorizačního kódu s PKCE.
/token koncový bod se používá pomocí toku autorizačního kódu , který udržuje token skrytý před prohlížečem.

Reklamace

Když používáte Azure AD B2C, máte jemně odstupňovanou kontrolu nad obsahem vašich tokenů. Můžete nakonfigurovat toky uživatelů a vlastní zásady k odesílání určitých sad uživatelských dat v nárocích, které jsou pro vaši aplikaci potřeba. Tyto deklarace identity mohou zahrnovat standardní vlastnosti, jako je displayName a emailAddress. Vaše aplikace můžou tyto deklarace identity použít k bezpečnému ověřování uživatelů a požadavků.

Deklarace identity v tokenech ID se nevrací v žádném konkrétním pořadí. Nové nároky je možné kdykoli zavést v ID tokenech. Vaše aplikace by se neměla rozbít, když se zavádějí nové nároky. Do vašich deklarací můžete také zahrnout vlastní atributy uživatele.

Následující tabulka uvádí deklarace identity, které můžete očekávat v tokenech ID a přístupových tokenech vydaných službou Azure AD B2C.

Název	Tvrzení	Příklad hodnoty	Popis
Obecenstvo	`aud`	`00001111-aaaa-2222-bbbb-3333cccc4444`	Identifikuje zamýšlený příjemce tokenu. Pro Azure AD B2C je cílovou skupinou ID aplikace. Vaše aplikace by měla tuto hodnotu ověřit a odmítnout token, pokud se neshoduje. Cílová skupina je synonymem prostředku.
Vydavatel	`iss`	`https://<tenant-name>.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/`	Identifikuje službu tokenů zabezpečení (STS), která vytváří a vrací token. Identifikuje také adresář, ve kterém byl uživatel ověřen. Vaše aplikace by měla ověřit deklaraci identity vystavitele, aby se ujistila, že token pochází z příslušného koncového bodu.
Vydáno dne	`iat`	`1438535543`	Čas vydání tokenu vyjádřený epochou.
Čas vypršení platnosti	`exp`	`1438539443`	Čas, kdy se token stane neplatným, vyjádřený epochou. Aplikace by měla tuto deklaraci identity použít k ověření platnosti životnosti tokenu.
Ne před	`nbf`	`1438535543`	Čas, kdy se token stane platným, vyjádřený v časové epoše. Tento čas je obvykle stejný jako čas vydání tokenu. Aplikace by měla tuto deklaraci identity použít k ověření platnosti životnosti tokenu.
Verze	`ver`	`1.0`	Verze tokenu ID definovaná službou Azure AD B2C.
Hodnota hash kódu	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Hash kódu je zahrnut v tokenu ID pouze v případech, kdy je token vydán společně s autorizačním kódem OAuth 2.0. K ověření pravosti autorizačního kódu lze použít hodnotu hash kódu. Další informace o tom, jak provést toto ověření, naleznete v rámci specifikace OpenID Connect .
Hodnota hash přístupového tokenu	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	V ID tokenu je zahrnuta hodnota hash přístupového tokenu pouze tehdy, když je token vystaven společně s přístupovým tokenem OAuth 2.0. K ověření pravosti přístupového tokenu lze použít hodnotu hash přístupového tokenu. Další informace o provedení tohoto ověření najdete ve specifikaci OpenID Connect
Příležitostný	`nonce`	`12345`	Nonce je strategie, která se používá ke zmírnění útoků na přehrání tokenů. Aplikace může v žádosti o autorizaci zadat nonce pomocí parametru dotazu `nonce`. Hodnota, kterou zadáte v požadavku, se beze změny uvede v nároku `nonce` pouze v ID tokenu. Tento nárok umožňuje vaší aplikaci ověřit hodnotu s hodnotou uvedenou v žádosti. Během procesu ověření tokenu ID by vaše aplikace měla toto ověření provést.
Předmět	`sub`	`aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb`	Subjekt, o kterém token určuje informace, například uživatel aplikace. Tato hodnota je neměnná a nedá se znovu přiřadit ani znovu použít. Dá se použít k bezpečnému provedení kontrol autorizace, jako je například použití tokenu pro přístup k prostředku. Ve výchozím nastavení se deklarace identity subjektu naplní ID objektu uživatele v adresáři.
Referenční informace ke třídě kontextu ověřování	`acr`	Není relevantní	Používá se pouze se staršími zásadami.
Zásady architektury důvěryhodnosti	`tfp`	`b2c_1_signupsignin1`	Název zásady použité k získání tokenu ID.
Čas ověřování	`auth_time`	`1438535543`	Čas, kdy uživatel naposledy zadal přihlašovací údaje, vyjádřený epochou. Neexistuje žádný rozdíl v tom, zda ověřování představuje nové přihlášení, relaci jednotného přihlášení (SSO) nebo jiný typ přihlášení. `auth_time` je čas, kdy aplikace (nebo uživatel) naposledy iniciovala pokus o ověření v Azure AD B2C. Metoda použitá k ověření není odlišná.
Obor	`scp`	`Read`	Oprávnění udělená zdroji pro přístupový token. Více udělených oprávnění je odděleno mezerou.
Autorizovaná strana	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	ID aplikace klientské aplikace, která žádost iniciovala.

Konfigurace

K správě životností tokenů zabezpečení generovaných službou Azure AD B2C se používají následující vlastnosti:

Doba platnosti ID tokenu pro přístup & (v minutách) – doba platnosti OAuth 2.0 tokenu použitého k dosažení přístupu k chráněnému prostředku. Výchozí hodnota je 60 minut. Minimální (včetně) je 5 minut. Maximum (včetně) je 1 440 minut.
životnosti tokenu aktualizace (dny) – maximální časové období, před kterým lze obnovovací token použít k získání nového přístupového tokenu nebo tokenu ID. Časové období zahrnuje také získání nového refresh tokenu, pokud vaše aplikace má přidělen scope offline_access. Výchozí hodnota je 14 dní. Minimum (včetně) je jeden den. Maximální (včetně) je 90 dní.
životnost posuvného okna tokenu aktualizace (dny) – po uplynutí tohoto časového období je uživatel nucen znovu provést ověření bez ohledu na dobu platnosti posledního obnovovacího tokenu získaného aplikací. Lze jej zadat pouze v případě, že je přepínač nastaven na Omezené. Musí být větší nebo rovna hodnotě životnosti tokenu aktualizace (dny). Pokud je přepínač nastavený na Bez vypršení platnosti, nemůžete zadat konkrétní hodnotu. Výchozí hodnota je 90 dní. Minimum (včetně) je jeden den. Maximální (včetně) je 365 dní.

Následující případy použití jsou povoleny pomocí těchto vlastností:

Umožňuje uživateli zůstat přihlášený k mobilní aplikaci po neomezenou dobu, pokud je uživatel v aplikaci neustále aktivní. Životnost posuvného okna tokenu aktualizace (dny) můžete ve svém uživatelském toku přihlášení nastavit na bez vypršení platnosti.
Splnění požadavků vašeho odvětví na zabezpečení a dodržování předpisů nastavením odpovídajících životností přístupových tokenů

Tato nastavení nejsou k dispozici pro uživatelské procesy resetování hesla.

Kompatibilita

K správěkompatibility tokenů se používají následující vlastnosti:

deklarace vystavitele (iss) – Tato vlastnost identifikuje tenanta Azure AD B2C, který token vystavil. Výchozí hodnota je https://<domain>/{B2C tenant GUID}/v2.0/. Hodnota https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ zahrnuje identifikátory tenanta Azure AD B2C i toku uživatele, který byl použit v požadavku na token. Pokud vaše aplikace nebo knihovna potřebuje, aby Azure AD B2C splňovala specifikaci OpenID Connect Discovery 1.0, použijte tuto hodnotu.
Nárok subjektu (sub) – Tato vlastnost identifikuje entitu, pro kterou token deklaruje informace. Výchozí hodnota je ID objektu, který vyplní nárok sub v tokenu s ID objektu uživatele. Hodnota Nepodporovaná je poskytována pouze pro zpětnou kompatibilitu. Doporučujeme přepnout na ObjectID, jakmile budete moct.
Deklarace identity představující ID zásady – Tato vlastnost identifikuje typ deklarace identity, do kterého se vyplní název zásady použitý v požadavku tokenu. Výchozí hodnota je tfp. Hodnota acr je poskytována pouze pro zpětnou kompatibilitu.

Průchozí

Když se spustí cesta uživatele, Azure AD B2C obdrží přístupový token od zprostředkovatele identity. Azure AD B2C používá tento token k načtení informací o uživateli. V toku uživatele povolíte nárok, abyste token přenesli prostřednictvím do aplikací, které zaregistrujete v Azure AD B2C. Vaše aplikace musí používat doporučený tok uživatele , aby mohla využít předání tokenu v podobě deklarace identity.

Azure AD B2C v současné době podporuje předávání přístupového tokenu zprostředkovatelů identity OAuth 2.0, mezi které patří Facebook a Google. Pro všechny ostatní zprostředkovatele identity se deklarace identity vrátí prázdná.

Ověřování

Pokud chcete token ověřit, měla by aplikace zkontrolovat podpis i deklarace identity tokenu. V závislosti na preferovaném jazyce je k dispozici mnoho opensourcových knihoven pro ověřování JWT. Doporučujeme, abyste tyto možnosti prozkoumali a neimplementovali vlastní logiku ověřování.

Ověření podpisu

JWT obsahuje tři segmenty: záhlaví, těloa podpis. Segment podpisu lze použít k ověření pravosti tokenu, aby ji vaše aplikace důvěřovala. Tokeny Azure AD B2C jsou podepsané pomocí standardních asymetrických šifrovacích algoritmů, jako je RSA 256.

Hlavička tokenu obsahuje informace o klíči a metodě šifrování použité k podepsání tokenu:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

Hodnota deklarace je algoritmus, který se použil k podepsání tokenu. Hodnotou nároku dítě je veřejný klíč, který byl použit k podepsání tokenu. Kdykoliv může Azure AD B2C podepsat token pomocí libovolné sady párů veřejného a privátního klíče. Azure AD B2C pravidelně obměňuje možnou sadu klíčů. Vaše aplikace by měla být navržená tak, aby automaticky zpracovávala tyto klíčové změny. Rozumná frekvence kontroly aktualizací veřejných klíčů používaných službou Azure AD B2C je každých 24 hodin. Aby bylo možné zpracovat neočekávané změny klíče, měla by být aplikace napsaná tak, aby znovu načetla veřejné klíče v případě, že obdrží neočekávanou hodnotu kid.

Azure AD B2C má koncový bod metadat OpenID Connect. Pomocí tohoto koncového bodu můžou aplikace za běhu požadovat informace o Azure AD B2C. Tyto informace zahrnují koncové body, obsah tokenů a podpisové klíče tokenů. Váš tenant Azure AD B2C obsahuje dokument s metadaty JSON pro každou politiku. Dokument metadat je objekt JSON, který obsahuje několik užitečných informací. Metadata obsahují jwks_uri, která poskytuje umístění sady veřejných klíčů, které se používají k podepisování tokenů. Zde je poskytováno toto umístění, ale nejlepší je získat umístění dynamicky pomocí dokumentu metadat a analýzy jwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

Dokument JSON umístěný na této adrese URL obsahuje všechny informace o veřejném klíči používané v určitém okamžiku. Aplikace může pomocí deklarace identity kid v hlavičce JWT vybrat veřejný klíč v dokumentu JSON, který se používá 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.

Dokument metadat pro zásady B2C_1_signupsignin1 v tenantovi contoso.onmicrosoft.com se nachází na adrese:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Pokud chcete zjistit, které zásady se použily k podepsání tokenu (a kam přejít k vyžádání metadat), máte dvě možnosti. Nejprve je název zásady součástí tfp (výchozí) nebo acr nároku (podle konfigurace) v tokenu. Můžete analyzovat nároky z těla JWT dekódováním těla pomocí base-64 a deserializací výsledného řetězce JSON. Nárok tfp nebo acr je název zásady používané k vydávání tokenu. Druhou možností je zakódovat zásadu v hodnotě parametru state při vydání požadavku a pak dekódovat, aby bylo možné určit, které zásady se použily. Obě metody jsou platné.

Azure AD B2C používá algoritmus RS256, který je založený na specifikaci RFC 3447. Veřejný klíč se skládá ze dvou komponent: modulu RSA (n) a veřejného exponentu RSA (e). Hodnoty n a e můžete programově převést na formát certifikátu pro ověření tokenu.

Popis, jak provést ověření podpisu, je mimo rozsah tohoto dokumentu. K dispozici je mnoho opensourcových knihoven, které vám pomůžou ověřit token.

Ověření nároků

Když vaše aplikace nebo rozhraní API obdrží token ID, mělo by také provést několik kontrol deklarací identity v tokenu ID. Je třeba zkontrolovat následující nároky.

aplikace – ověřuje, že token ID byl určen vaší aplikaci.
před a vypršením platnosti – ověřuje, že nevypršela platnost tokenu ID.
vystavitel tokenu – Ověřuje, že token byl vydán službou Azure AD B2C vaší aplikaci.
nonce – strategie pro zmírnění útoku přehráním tokenu.

Úplný seznam ověření, která má vaše aplikace provést, najdete ve specifikaci OpenID Connect.

Přečtěte si další informace o tom, jak používat přístupové tokeny.

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-04-01