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.
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.
Pomocí udělení autorizačního kódu OAuth 2.0 v aplikacích nainstalovaných na zařízení můžete získat přístup k chráněným prostředkům, jako jsou webová rozhraní API. Pomocí implementace Azure Active Directory B2C (Azure AD B2C) OAuth 2.0 můžete do jednostrákových, mobilních a desktopových aplikací přidávat úlohy registrace, přihlašování a další úlohy správy identit. V tomto článku popisujeme, jak odesílat a přijímat zprávy HTTP bez použití opensourcových knihoven. Tento článek je nezávislý na jazyce. Pokud je to možné, doporučujeme používat podporované knihovny MICROSOFT Authentication Library (MSAL). Podívejte se na ukázkové aplikace, které používají MSAL.
Tok autorizačního kódu OAuth 2.0 je popsaný v části 4.1 specifikace OAuth 2.0. Můžete ho použít k ověřování a autorizaci ve většině typů aplikací, včetně webových aplikací, jednostrákových aplikací a nativně nainstalovaných aplikací. Tok autorizačního kódu OAuth 2.0 můžete použít k bezpečnému získání přístupových tokenů a obnovovacích tokenů pro vaše aplikace, které se dají použít pro přístup k prostředkům zabezpečeným autorizačním serverem. Obnovovací token umožňuje klientovi získat nové přístupové tokeny (a aktualizovat) po vypršení platnosti přístupového tokenu, obvykle po jedné hodině.
Tento článek se zaměřuje na tok autorizačního kódu OAuth 2.0 pro veřejné klienty . Veřejný klient je libovolná klientská aplikace, která nemůže být důvěryhodná, aby bezpečně zachovala integritu tajného hesla. To zahrnuje jednostrákové aplikace, mobilní aplikace, desktopové aplikace a v podstatě jakoukoli aplikaci, která neběží na serveru.
Poznámka:
Pokud chcete přidat správu identit do webové aplikace pomocí Azure AD B2C, použijte OpenID Connect místo OAuth 2.0.
Azure AD B2C rozšiřuje standardní toky OAuth 2.0, aby dělaly více než jednoduché ověřování a autorizace. Představuje uživatelský tok. Pomocí toků uživatelů můžete pomocí OAuth 2.0 do aplikace přidat uživatelská prostředí, jako je registrace, přihlášení a správa profilů. Zprostředkovatelé identity, kteří používají protokol OAuth 2.0, zahrnují Amazon, Microsoft Entra ID, Facebook, GitHub, Google a LinkedIn.
Pokud chcete vyzkoušet požadavky HTTP v tomto článku:
- Nahraďte
{tenant}názvem vašeho tenanta Azure AD B2C. - Nahraďte
00001111-aaaa-2222-bbbb-3333cccc4444ID aplikace, kterou jste dříve zaregistrovali ve svém tenantovi Azure AD B2C. - Nahraďte
{policy}názvem zásady, kterou jste vytvořili ve svém tenantovi, napříkladb2c_1_sign_in.
Nastavení přesměrovací URI vyžadované pro aplikace s jednou stránkou
Tok autorizačního kódu pro jednostrákové aplikace vyžaduje další nastavení. Postupujte podle pokynů pro vytvoření jednostránkové aplikace, abyste správně označili identifikátor URI přesměrování jako povolený pro CORS. Pokud chcete aktualizovat existující přesměrovací URI, abyste povolili CORS, můžete kliknout na nabídku migrace v části Web na kartě Ověřováníregistrace aplikace. Případně můžete otevřít editor manifestu registrace aplikací a nastavit type pole pro přesměrovací URI na spa v části replyUrlsWithType.
spa Typ přesměrování je zpětně kompatibilní s implicitními toky. Aplikace, které v současné době používají implicitní tok k získání tokenů, můžou bez problémů přejít na typ přesměrování URI spa a pokračovat v používání implicitního toku.
1. Získání autorizačního kódu
Tok autorizačního kódu začíná klientem, který uživatele nasměruje na /authorize koncový bod. Jedná se o interaktivní část toku, kde uživatel provede akci. V tomto požadavku klient indikuje v parametru scope oprávnění, která potřebuje získat od uživatele. Následující příklady (s koncem řádků pro čitelnost) ukazují, jak získat autorizační kód. Pokud testujete tento požadavek GET HTTP, použijte prohlížeč.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
| Parametr | Povinné? | Popis |
|---|---|---|
| {nájemník} | Povinné | Název tenanta Azure AD B2C |
| {politika} | Povinné | Tok uživatele, který se má spustit. Zadejte název toku uživatele, který jste vytvořili v tenantovi Azure AD B2C. Například: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile. |
| client_id (identifikátor klienta) | Povinné | ID aplikace přiřazené k aplikaci na webu Azure Portal. |
| typ odpovědi | Povinné | Typ odpovědi, který musí obsahovat code pro tok autorizačního kódu. Token ID můžete obdržet, pokud ho zahrnete do typu odpovědi, například code+id_token, a v tomto případě musí rozsah obsahovat openid. |
| URI přesměrování (redirect_uri) | Povinné | Identifikátor URI přesměrování vaší aplikace, kam jsou odesílány a odkud jsou přijímány odpovědi na ověřování vaší aplikací. Musí přesně odpovídat některé z přesměrovacích URI, které jste zaregistrovali na portálu, s tím rozdílem, že musí být zakódovaná jako URL. |
| rozsah působnosti | Povinné | Seznam rozsahů oddělených mezerami. Obor openid označuje oprávnění k přihlášení uživatele a získání dat o uživateli ve formě tokenů ID. Obor offline_access je volitelný pro webové aplikace. Označuje, že vaše aplikace potřebuje obnovovací token pro rozšířený přístup k prostředkům. ID klienta označuje, že vystavený token je určený pro použití zaregistrovaným klientem Azure AD B2C. Označuje https://{tenant-name}/{app-id-uri}/{scope} oprávnění k chráněným prostředkům, jako je webové rozhraní API. Další informace najdete v tématu Žádost o přístupový token. |
| mód odezvy | Doporučeno | Metoda, kterou použijete k odeslání výsledného autorizačního kódu zpět do aplikace. Může to být query, form_postnebo fragment. |
| stav / stát | Doporučeno | Hodnota zahrnutá v požadavku, která může být řetězcem libovolného obsahu, který chcete použít. Obvykle se používá náhodně vygenerovaná jedinečná hodnota, aby se zabránilo útokům na padělání požadavků mezi weby. Stav se také používá ke kódování informací o stavu uživatele v aplikaci před tím, než došlo k žádosti o ověření. Například stránka, na které se uživatel nacházel, nebo uživatelský tok, který byl proveden. |
| výzva | Volitelný | Typ interakce uživatele, který se vyžaduje. V současné době je loginjedinou platnou hodnotou , která vynutí, aby uživatel zadal své přihlašovací údaje k této žádosti. Jednotné přihlašování nebude fungovat. |
| programovací výzva | doporučeno / povinné | Slouží k zabezpečení autorizačního kódu prostřednictvím ověřovacího klíče pro výměnu kódu (PKCE). Vyžaduje se, pokud code_challenge_method je zahrnuta. Ve své aplikaci musíte přidat logiku pro generování code_verifier a code_challenge.
code_challenge je hodnota hash SHA256 zakódovaná pomocí Base64 určeného pro URL z code_verifier. Uložíte code_verifier ve vaší aplikaci pro pozdější použití a dále odešlete code_challenge spolu s žádostí o autorizaci. Další informace najdete v dokumentu PKCE RFC. Tato možnost se teď doporučuje pro všechny typy aplikací – nativní aplikace, služby SPA a důvěrné klienty, jako jsou webové aplikace. |
code_challenge_method |
doporučeno / povinné | Metoda používaná ke kódování code_verifier pro parametr code_challenge.
Mělo by být S256, ale specifikace umožňuje použití plain, pokud klient z nějakého důvodu nemůže podporovat SHA256. Pokud vyloučíte code_challenge_method, ale přesto zahrnout code_challenge, pak code_challenge se předpokládá, že je prostý text. Platforma Microsoft Identity Platform podporuje obojí plain i S256. Další informace najdete v dokumentu PKCE RFC. To se vyžaduje pro jednostránkové aplikace používající tok autorizačního kódu. |
| nápověda k přihlášení | Ne | Dá se použít k předvyplnění pole pro uživatelské jméno na přihlašovací stránce. Další informace najdete v tématu Předvyplnění přihlašovacího jména. |
| nápověda pro doménu | Ne | Poskytuje nápovědu pro Azure AD B2C o zprostředkovateli sociální identity, který by se měl použít pro přihlášení. Pokud je zahrnuta platná hodnota, uživatel přejde přímo na přihlašovací stránku zprostředkovatele identity. Další informace najdete v tématu Přesměrování přihlášení k poskytovateli sociálních sítí. |
| Vlastní parametry | Ne | Vlastní parametry, které lze použít s vlastními zásadami. Například identifikátor URI dynamického vlastního obsahu stránky nebo překladače deklarací identity klíč-hodnota. |
V tomto okamžiku se uživateli zobrazí výzva k dokončení pracovního postupu toku uživatele. To může zahrnovat zadání uživatelského jména a hesla uživatele, přihlášení pomocí sociální identity, registraci adresáře nebo jakéhokoli jiného počtu kroků. Akce uživatelů závisí na tom, jak je definovaný tok uživatele.
Po dokončení toku uživatele vrátí ID Microsoft Entra odpověď na vaši aplikaci s hodnotou, kterou jste použili pro redirect_uri. Používá metodu zadanou v parametru response_mode . Odpověď je naprosto stejná pro každý scénář akcí uživatele, nezávisle na toku uživatele, který byl proveden.
Úspěšná odpověď, která používá response_mode=query , vypadá takto:
GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq... // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response // the value provided in the request
| Parametr | Popis |
|---|---|
| kód | Autorizační kód, který aplikace požadovala. Aplikace může použít autorizační kód k vyžádání přístupového tokenu pro cílový prostředek. Autorizační kódy jsou krátkodobé. Obvykle vyprší po přibližně 10 minutách. |
| stav / stát | Podívejte se na úplný popis v tabulce v předchozí části.
state Pokud je parametr součástí požadavku, měla by se v odpovědi zobrazit stejná hodnota. Aplikace by měla ověřit, že state hodnoty v požadavku a odpovědi jsou stejné. |
Chybové odpovědi mohou být také odeslány na zavedenou URI, aby je aplikace mohla správně zvládnout.
GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
| Parametr | Popis |
|---|---|
| chyba | Řetězec kódu chyby, který můžete použít ke klasifikaci typů chyb, ke kterým dochází. Můžete také použít řetězec, abyste mohli reagovat na chyby. |
| popis chyby | Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování. |
| stav / stát | Podívejte se na úplný popis v předchozí tabulce.
state Pokud je parametr součástí požadavku, měla by se v odpovědi zobrazit stejná hodnota. Aplikace by měla ověřit, že state hodnoty v požadavku a odpovědi jsou stejné. |
2. Získání přístupového tokenu
Teď, když jste získali autorizační kód, můžete vyměnit code za token pro zamýšlený prostředek odesláním požadavku POST do koncového /token bodu. V Azure AD B2C můžete požádat o přístupové tokeny pro jiná rozhraní API obvyklým zadáním jejich oborů v požadavku.
Můžete také požádat o přístupový token pro vlastní back-endové webové rozhraní API vaší aplikace podle konvence použití ID klienta aplikace jako požadovaného oboru (což bude mít za následek přístupový token s tímto ID klienta jako cílovou skupinu):
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
| Parametr | Povinné? | Popis |
|---|---|---|
| {nájemník} | Povinné | Název tenanta Azure AD B2C |
| {politika} | Povinné | Tok uživatele, který byl použit k získání autorizačního kódu. V tomto požadavku nemůžete použít jiný uživatelský tok. |
| client_id (identifikátor klienta) | Povinné | ID aplikace přiřazené k aplikaci na webu Azure Portal. |
| tajný klíč klienta | Ano, ve službě Web Apps | Tajný klíč aplikace vygenerovaný na webu Azure Portal. Tajné kódy klienta se používají v tomto toku pro scénáře webové aplikace, kde klient může bezpečně uložit tajný klíč klienta. V případě scénářů nativní aplikace (veřejného klienta) se tajné kódy klientů nedají bezpečně uložit, a proto se v tomto volání nepoužívají. Pokud používáte tajný klíč klienta, pravidelně ho změňte. |
| typ_grantu | Povinné | Typ grantu. Pro tok autorizačního kódu typ udělení musí být authorization_code. |
| rozsah působnosti | Doporučeno | Seznam rozsahů oddělených mezerami. Jedna hodnota oboru označuje Azure AD B2C obě požadovaná oprávnění. Použití ID klienta jako oboru označuje, že vaše aplikace potřebuje přístupový token, který lze použít pro vlastní službu nebo webové rozhraní API reprezentované stejným ID klienta. Obor offline_access označuje, že vaše aplikace potřebuje obnovovací token pro dlouhodobý přístup k prostředkům. Obor můžete použít openid také k vyžádání tokenu ID z Azure AD B2C. |
| kód | Povinné | Autorizační kód, který jste získali z koncového bodu /authorize. |
| URI přesměrování (redirect_uri) | Povinné | Adresa URI pro přesměrování aplikace, kde jste obdrželi autorizační kód. |
| ověřovač_kódu | Doporučené | To samé code_verifier se použilo k získání autorizačního kódu. Vyžaduje se, pokud byl PKCE použit v žádosti o udělení autorizačního kódu. Další informace najdete v dokumentu PKCE RFC. |
Pokud testujete tento požadavek POST HTTP, můžete použít libovolného klienta HTTP, jako je Microsoft PowerShell.
Úspěšná odpověď tokenu vypadá takto:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parametr | Popis |
|---|---|
| ne dříve než | Čas, kdy se token považuje za platný, v epochovém čase. |
| typ_tokenu | Hodnota typu tokenu. Jediným typem, který Microsoft Entra ID podporuje, je Bearer. |
| access_token (přístupový token) | Podepsaný webový token JSON (JWT), který jste požadovali. |
| rozsah působnosti | Obory, pro které je token platný. Obory můžete použít také k ukládání tokenů do mezipaměti pro pozdější použití. |
| vyprší za | Doba platnosti tokenu (v sekundách). |
| aktualizační_token | Obnovovací token OAuth 2.0 Aplikace může tento token použít k získání dalších tokenů po vypršení platnosti aktuálního tokenu. Obnovovací tokeny jsou určeny pro dlouhodobé použití. Můžete je použít k zachování přístupu k prostředkům po delší dobu. Další informace najdete v referenčních informacích k tokenu Azure AD B2C. |
Chybové odpovědi vypadají takto:
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| Parametr | Popis |
|---|---|
| chyba | Řetězec kódu chyby, který můžete použít ke klasifikaci typů chyb, ke kterým dochází. Můžete také použít řetězec, abyste mohli reagovat na chyby. |
| popis chyby | Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování. |
3. Použití tokenu
Teď, když jste úspěšně získali přístupový token, můžete token použít v požadavcích na back-endová webová rozhraní API tak, že ho zahrnete do Authorization hlavičky:
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
4. Aktualizace tokenu
Přístupové tokeny a tokeny ID jsou krátkodobé. Po vypršení jejich platnosti je nutné je aktualizovat, abyste mohli dál přistupovat k prostředkům. Když aktualizujete přístupový token, Azure AD B2C vrátí nový token. Aktualizovaný přístupový token bude mít aktualizované hodnoty prohlášení nbf (ne dříve), iat (vydáno) a exp (vypršení platnosti). Všechny ostatní hodnoty nároku jsou stejné jako původně vydaný přístupový token.
Pokud chcete token aktualizovat, odešlete do koncového /token bodu další požadavek POST. Tentokrát zadejte refresh_token místo code:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| Parametr | Povinné? | Popis |
|---|---|---|
| {nájemník} | Povinné | Název tenanta Azure AD B2C |
| {politika} | Povinné | Tok uživatele, který byl použit k získání původního obnovovacího tokenu. V tomto požadavku nemůžete použít jiný uživatelský tok. |
| client_id (identifikátor klienta) | Povinné | ID aplikace přiřazené k aplikaci na webu Azure Portal. |
| tajný klíč klienta | Ano, ve službě Web Apps | Tajný klíč aplikace vygenerovaný na webu Azure Portal. Tajné kódy klienta se používají v tomto toku pro scénáře webové aplikace, kde klient může bezpečně uložit tajný klíč klienta. V případě scénářů nativní aplikace (veřejného klienta) se tajné kódy klientů nedají bezpečně uložit, a proto se v tomto volání nepoužívají. Pokud používáte tajný klíč klienta, pravidelně ho změňte. |
| typ_grantu | Povinné | Typ grantu. Pro tuto část toku autorizačního kódu musí být typ udělení refresh_token. |
| rozsah působnosti | Doporučeno | Seznam rozsahů oddělených mezerami. Jedna hodnota rozsahu označuje Microsoft Entra ID oprávnění, která jsou požadována. Použití ID klienta jako oboru označuje, že vaše aplikace potřebuje přístupový token, který lze použít pro vlastní službu nebo webové rozhraní API reprezentované stejným ID klienta. Obor offline_access označuje, že vaše aplikace potřebuje obnovovací token pro dlouhodobý přístup k prostředkům. Obor můžete použít openid také k vyžádání tokenu ID z Azure AD B2C. |
| URI přesměrování (redirect_uri) | Volitelný | Adresa URI pro přesměrování aplikace, kde jste obdrželi autorizační kód. |
| aktualizační_token | Povinné | Původní obnovovací token, který jste získali ve druhé fázi procesu. |
Úspěšná odpověď tokenu vypadá takto:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parametr | Popis |
|---|---|
| ne dříve než | Čas, kdy se token považuje za platný, v epochovém čase. |
| typ_tokenu | Hodnota typu tokenu. Jediným typem, který Microsoft Entra ID podporuje, je Bearer. |
| access_token (přístupový token) | Podepsaný JWT, o který jste požádali. |
| rozsah působnosti | Obory, pro které je token platný. Obory můžete použít také k ukládání tokenů do mezipaměti pro pozdější použití. |
| vyprší za | Doba platnosti tokenu (v sekundách). |
| aktualizační_token | Obnovovací token OAuth 2.0 Aplikace může tento token použít k získání dalších tokenů po vypršení platnosti aktuálního tokenu. Obnovovací tokeny jsou dlouhodobé a dají se použít k zachování přístupu k prostředkům po delší dobu. Další informace najdete v referenčních informacích k tokenu Azure AD B2C. |
Chybové odpovědi vypadají takto:
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| Parametr | Popis |
|---|---|
| chyba | Řetězec kódu chyby, který můžete použít ke klasifikaci typů chyb, ke kterým dochází. Můžete také použít řetězec, abyste mohli reagovat na chyby. |
| popis chyby | Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování. |
Použití vlastního adresáře Azure AD B2C
Pokud chcete tyto žádosti vyzkoušet sami, proveďte následující kroky. Nahraďte ukázkové hodnoty, které jsme použili v tomto článku, vlastními hodnotami.
- Vytvořte adresář Azure AD B2C. V požadavcích použijte název adresáře.
- Vytvořte aplikaci pro získání ID aplikace a identifikátoru URI přesměrování. Do aplikace zahrňte nativního klienta.
- Vytvořte toky uživatelů , abyste získali názvy toků uživatelů.