Tok autorizačního kódu OAuth 2.0 v Azure Active Directory B2C

Článek
11/06/2023

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-b8bbc0b29dc6 ID 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říklad b2c_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_up`nebo `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_post`nebo `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 `login`jedinou 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_code`typ 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_token`typ 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.