Tok autorizačního kódu OAuth 2.0 v Azure Active Directory B2C
Udělení autorizačního kódu OAuth 2.0 v aplikacích nainstalovaných na zařízení můžete použít k získání přístupu k chráněným prostředkům, jako jsou webová rozhraní API. Pomocí implementace OAuth 2.0 v Azure Active Directory B2C (Azure AD B2C) můžete do jednostránkových, mobilních a desktopových aplikací přidat registraci, přihlášení a další úlohy správy identit. Tento článek je nezávislý na jazyce. V tomto článku popisujeme, jak odesílat a přijímat zprávy HTTP bez použití opensourcových knihoven. 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ánkových aplikací a nativně nainstalovaných aplikací. Pomocí toku autorizačního kódu OAuth 2.0 můžete bezpečně získat přístupové tokeny a aktualizovat tokeny pro vaše aplikace, které lze 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é (a obnovovací) tokeny 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 jakákoli klientská aplikace, které nelze důvěřovat, aby bezpečně udržovala integritu tajného hesla. To zahrnuje jednostránkové aplikace, mobilní aplikace, desktopové aplikace a v podstatě všechny aplikace, které neběží na serveru.
Poznámka
Pokud chcete do webové aplikace přidat správu identit pomocí Azure AD B2C, použijte místo OAuth 2.0 OpenID Connect.
Azure AD B2C rozšiřuje standardní toky OAuth 2.0 o víc než jen jednoduché ověřování a autorizaci. Představuje tok uživatele. S toky uživatelů můžete použít OAuth 2.0 k přidání uživatelského prostředí do vaší aplikace, jako je registrace, přihlášení a správa profilů. Mezi zprostředkovatele identity, kteří používají protokol OAuth 2.0, patří 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
90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6ID 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í identifikátoru URI přesměrování vyžadované pro jednostránkové aplikace
Tok autorizačního kódu pro jednostránkové aplikace vyžaduje další nastavení. Postupujte podle pokynů k vytvoření jednostránkové aplikace a správně označte identifikátor URI přesměrování jako povolený pro CORS. Pokud chcete aktualizovat existující identifikátor URI přesměrování, abyste povolili CORS, můžete kliknout na výzvu k migraci v části Web na kartě Ověřováníregistrace aplikace. Případně můžete otevřít editor manifestu Registrace aplikací a v části nastavit type pole pro identifikátor URI spareplyUrlsWithType přesměrování.
Typ spa přesměrování je zpětně kompatibilní s implicitními toky. Aplikace, které aktuálně používají implicitní tok k získání tokenů, se můžou bez problémů přesunout na spa typ identifikátoru URI přesměrování 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á tím, že klient nasměruje uživatele na /authorize koncový bod. Toto je interaktivní část toku, ve které uživatel provede akci. V tomto požadavku klient v parametru scope označí oprávnění, která musí 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%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é? | Description |
|---|---|---|
| {tenant} | Vyžadováno | Název tenanta Azure AD B2C |
| {policy} | Vyžadováno | Tok uživatele, který se má spustit. Zadejte název toku uživatele, který jste vytvořili v tenantovi Azure AD B2C. Příklad: b2c_1_sign_in, b2c_1_sign_upnebo b2c_1_edit_profile. |
| client_id | Vyžadováno | ID aplikace přiřazené vaší aplikaci v Azure Portal. |
| response_type | Vyžadováno | Typ odpovědi, který musí obsahovat code 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í obor zahrnovat openid. |
| redirect_uri | Vyžadováno | Identifikátor URI přesměrování vaší aplikace, kde vaše aplikace odesílá a přijímá odpovědi na ověřování. Musí přesně odpovídat jednomu z identifikátorů URI pro přesměrování, které jste zaregistrovali na portálu, s tím rozdílem, že musí být zakódovaná adresa URL. |
| scope | Vyžadováno | Seznam oborů 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 pro webové aplikace volitelný. Znamená to, že vaše aplikace bude pro rozšířený přístup k prostředkům potřebovat obnovovací token. Id klienta označuje, že vydaný token je určený pro použití klientem registrovaným 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 například webové rozhraní API. Další informace najdete v tématu Žádost o přístupový token. |
| response_mode | 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. |
| state | 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é byl uživatel, nebo tok uživatele, který se spustil. |
| Výzva | Volitelné | Typ požadované interakce uživatele. V současné době je loginjedinou platnou hodnotou , která uživatele přinutí zadat své přihlašovací údaje k danému požadavku. Jednotné přihlašování se neprojeví. |
| code_challenge | doporučená /povinná | Používá se k zabezpečení udělení autorizačního kódu prostřednictvím ověřovacího klíče pro výměnu kódu (PKCE). Povinné, pokud code_challenge_method je součástí. Do aplikace musíte přidat logiku, která vygeneruje code_verifier a code_challenge. Hodnota code_challenge je hash SHA256 zakódovaná adresa URL base64 objektu code_verifier. Uložíte ho code_verifier do aplikace pro pozdější použití a odešlete code_challenge spolu s žádostí o autorizaci. Další informace najdete v dokumentu RFC pkce. Tento postup 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čená /povinná | Metoda použitá ke kódování parametru code_verifiercode_challenge . Mělo by to být S256, ale specifikace umožňuje použít, pokud klient z nějakého plain důvodu nepodporuje SHA256. Pokud vyloučíte code_challenge_method, ale přesto zahrnete code_challenge, pak code_challenge se předpokládá, že se jedná o prostý text. Microsoft identity platform podporuje i plainS256. Další informace najdete v dokumentu RFC pkce. To se vyžaduje u jednostránkových aplikací, které používají tok autorizačního kódu. |
| login_hint | No | Dá se použít k předvyplnění pole přihlašovacího jména na přihlašovací stránce. Další informace najdete v tématu Předplňte přihlašovací jméno. |
| domain_hint | No | 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 | No | Vlastní parametry, které je možné použít s vlastními zásadami. Například dynamické vlastní identifikátory URI 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, přihlášení pomocí sociální identity, registraci adresáře nebo jakýkoli jiný počet kroků. Akce uživatelů závisí na tom, jak je tok uživatele definován.
Jakmile uživatel dokončí tok uživatele, Microsoft Entra ID vrátí aplikaci odpověď v hodnotě, 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á se 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 autorizační kód použít k vyžádání přístupového tokenu pro cílový prostředek. Autorizační kódy jsou velmi krátkodobé. Obvykle vyprší přibližně po 10 minutách. |
| state | Úplný popis najdete 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 jsou hodnoty v požadavku a odpovědi identické. |
Odpovědi na chyby je také možné odeslat na identifikátor URI přesměrování, aby je aplikace správně zpracovala:
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 |
|---|---|
| error | Řetězec kódu chyby, který můžete použít ke klasifikaci typů chyb, ke kterým dochází. Řetězec můžete také použít k reakci na chyby. |
| error_description | Konkrétní chybová zpráva, která vám může pomoct identifikovat původní příčinu chyby ověřování. |
| state | Úplný popis najdete 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 jsou hodnoty v požadavku a odpovědi identické. |
2. Získání přístupového tokenu
Teď, když jste získali autorizační kód, můžete token uplatnit code pro zamýšlený prostředek odesláním požadavku POST koncovému /token bodu. V Azure AD B2C můžete jako obvykle požádat o přístupové tokeny pro jiná rozhraní API tak, že v požadavku zadáte jejich obory.
Můžete také požádat o přístupový token pro vlastní back-endové webové rozhraní API vaší aplikace na základě konvence použití ID klienta aplikace jako požadovaného oboru (výsledkem bude přístupový token s tímto ID klienta jako "cílovou skupinou"):
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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
| Parametr | Povinné? | Description |
|---|---|---|
| {tenant} | Vyžadováno | Název vašeho tenanta Azure AD B2C |
| {policy} | Vyžadováno | Tok uživatele, který byl použit k získání autorizačního kódu. V tomto požadavku nelze použít jiný tok uživatele. |
| client_id | Vyžadováno | ID aplikace přiřazené vaší aplikaci v Azure Portal. |
| client_secret | Ano, v Web Apps | Tajný kód aplikace vygenerovaný v Azure Portal. Tajné kódy klienta se v tomto toku používají ve scénářích webových aplikací, kde klient může bezpečně uložit tajný klíč klienta. Ve scénářích s nativní aplikací (veřejným klientem) není možné bezpečně ukládat tajné kódy klienta, a proto se v tomto volání nepoužívají. Pokud používáte tajný klíč klienta, pravidelně ho měňte. |
| grant_type | Vyžadováno | Typ grantu. Pro tok autorizačního kódu musí být authorization_codetyp udělení . |
| scope | Doporučeno | Seznam oborů oddělených mezerami. Jedna hodnota oboru označuje, že se Microsoft Entra ID obou požadovaných oprávnění. Použití ID klienta jako oboru znamená, ž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 také použít openid k vyžádání tokenu ID z Azure AD B2C. |
| kód | Vyžadováno | Autorizační kód, který jste získali z koncového /authorize bodu. |
| redirect_uri | Vyžadováno | Identifikátor URI přesměrování aplikace, do které jste obdrželi autorizační kód. |
| code_verifier | Doporučené | Totéž code_verifier se použilo k získání autorizačního kódu. Vyžaduje se, pokud se pkce použila 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 nebo Postman.
Úspěšná odpověď tokenu vypadá takto:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parametr | Popis |
|---|---|
| not_before | Čas, kdy se token považuje za platný, v epoché době. |
| token_type | Hodnota typu tokenu. Jediný typ, který Microsoft Entra ID podporuje, je Bearer. |
| access_token | Podepsaný webový token JSON (JWT), který jste požadovali. |
| scope | Obory, pro které je token platný. Obory můžete také použít k ukládání tokenů do mezipaměti pro pozdější použití. |
| expires_in | Doba platnosti tokenu (v sekundách). |
| refresh_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é. 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 |
|---|---|
| error | Řetězec kódu chyby, který můžete použít ke klasifikaci typů chyb, ke kterým dochází. Řetězec můžete také použít k reakci na chyby. |
| error_description | 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 ho použít v požadavcích na back-endová webová rozhraní API tak, že ho Authorization zahrnete do hlavičky:
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
4. Aktualizujte token.
Přístupové tokeny a tokeny ID jsou krátkodobé. Po vypršení jejich platnosti je musíte aktualizovat, abyste mohli dál přistupovat k prostředkům. Při aktualizaci přístupového tokenu vrátí Azure AD B2C nový token. Aktualizovaný přístupový token bude mít aktualizované nbf hodnoty deklarací identity (ne dříve), iat (vydané v) a exp (vypršení platnosti). Všechny ostatní hodnoty deklarací identity budou 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 místo parametru refresh_tokencode:
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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| Parametr | Povinné? | Description |
|---|---|---|
| {tenant} | Vyžadováno | Název vašeho tenanta Azure AD B2C |
| {policy} | Vyžadováno | Tok uživatele, který byl použit k získání původního obnovovacího tokenu. V tomto požadavku nelze použít jiný tok uživatele. |
| client_id | Vyžadováno | ID aplikace přiřazené vaší aplikaci v Azure Portal. |
| client_secret | Ano, v Web Apps | Tajný kód aplikace vygenerovaný v Azure Portal. Tajné kódy klienta se v tomto toku používají ve scénářích webových aplikací, kde klient může bezpečně uložit tajný klíč klienta. Ve scénářích s nativní aplikací (veřejným klientem) není možné bezpečně ukládat tajné kódy klienta, a proto se v tomto volání nepoužívají. Pokud používáte tajný klíč klienta, pravidelně ho měňte. |
| grant_type | Vyžadováno | Typ grantu. Pro tuto část toku autorizačního kódu musí být refresh_tokentyp udělení . |
| scope | Doporučeno | Seznam oborů oddělených mezerami. Jedna hodnota oboru označuje, že se Microsoft Entra ID obou požadovaných oprávnění. Použití ID klienta jako oboru znamená, ž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 bude potřebovat obnovovací token pro dlouhodobý přístup k prostředkům. Obor můžete také použít openid k vyžádání tokenu ID z Azure AD B2C. |
| redirect_uri | Volitelné | Identifikátor URI přesměrování aplikace, do které jste obdrželi autorizační kód. |
| refresh_token | Vyžadováno | Původní obnovovací token, který jste získali v druhé části toku. |
Úspěšná odpověď tokenu vypadá takto:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parametr | Popis |
|---|---|
| not_before | Čas, kdy se token považuje za platný, v epoché době. |
| token_type | Hodnota typu tokenu. Jediný typ, který Microsoft Entra ID podporuje, je Bearer. |
| access_token | Podepsaný JWT, který jste požadovali. |
| scope | Obory, pro které je token platný. Obory můžete také použít k ukládání tokenů do mezipaměti pro pozdější použití. |
| expires_in | Doba platnosti tokenu (v sekundách). |
| refresh_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 je možné je použít k uchovává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 |
|---|---|
| error | Řetězec kódu chyby, který můžete použít ke klasifikaci typů chyb, ke kterým dochází. Řetězec můžete také použít k reakci na chyby. |
| error_description | 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 si 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 vašeho adresáře.
- Vytvořte aplikaci pro získání ID aplikace a identifikátoru URI přesměrování. Zahrňte do aplikace nativního klienta.
- Vytvořte toky uživatelů pro získání názvů toků uživatelů.