這很重要
自 2025 年 5 月 1 日起,Azure AD B2C 將不再可供新客戶購買。 在我們的常見問題中深入瞭解。
您可以在裝置上安裝的應用程式中使用 OAuth 2.0 授權碼授與,以存取受保護的資源,例如 Web API。 藉由使用 OAuth 2.0 的 Azure Active Directory B2C (Azure AD B2C) 實作,您可以將註冊、登入和其他身分識別管理工作新增至單頁、行動裝置和桌面應用程式。 在本文中,我們會說明如何在不使用任何開放原始碼連結庫的情況下傳送和接收 HTTP 訊息。 本文與語言無關。 如果可能,建議您使用支援的 Microsoft 驗證庫(MSAL)。 看看 使用 MSAL 的範例應用程式。
如需 OAuthh 2.0 授權碼流程的說明,請參閱 OAuth 2.0 規格的第 4.1 節。 您可以在大部分 的應用程式類型中使用它來進行驗證和授權,包括 Web 應用程式、單頁應用程式,以及原生安裝的應用程式。 您可以使用 OAuth 2.0 授權碼流程,安全地取得應用程式的存取令牌和重新整理令牌,這可用來存取 受授權伺服器保護的資源。 刷新令牌可讓用戶端在存取令牌到期後重新取得新的存取和刷新令牌,通常有效期為一小時。
本文著重於 公用用戶端 OAuth 2.0 授權碼流程。 公用用戶端是任何無法信任的用戶端應用程式,以安全地維護密碼的完整性。 這包括單頁應用程式、行動應用程式、傳統型應用程式,以及基本上未在伺服器上執行的任何應用程式。
備註
若要使用 Azure AD B2C 將身分識別管理新增至 Web 應用程式,請使用 OpenID Connect ,而不是 OAuth 2.0。
Azure AD B2C 擴充標準 OAuth 2.0 流程,以執行超越簡單驗證和授權的功能。 它引入使用者流程。 透過使用者流程,您可以使用 OAuth 2.0 將用戶體驗新增至您的應用程式,例如註冊、登入和配置檔管理。 使用 OAuth 2.0 通訊協議的識別提供者包括 Amazon、 Microsoft Entra ID、 Facebook、 GitHub、 Google 和 LinkedIn。
若要嘗試本文中的 HTTP 要求:
- 將
{tenant}取代為您的 Azure AD B2C 租用戶名稱。 - 請將
00001111-aaaa-2222-bbbb-3333cccc4444替換為您先前在 Azure AD B2C 租用戶中註冊的應用程式識別碼。 - 將
{policy}替換為您租戶中已建立的政策名稱,例如b2c_1_sign_in。
單頁應用程式所需的重新導向 URI 設定
單頁應用程式的授權碼流程需要一些額外的設定。 請遵循 建立單頁應用程式的 指示,將重新導向 URI 正確標示為針對 CORS 啟用。 若要更新現有的重新導向 URI 以啟用 CORS,您可以在應用程式註冊的 [驗證] 索引標籤標的 [Web] 區段中按下移轉提示。或者,您可以開啟應用程式註冊指令清單編輯器,並在 區段中將重新導向 URI 的type欄位設定spa為 replyUrlsWithType 。
spa 重定向類型與隱式流程向後相容。 目前使用隱含流程來取得權杖的應用程式可移至 spa 重新導向 URI 類型,而不會發生問題,並可繼續使用隱含流程。
1.取得授權碼
授權碼流程始於用戶端將使用者導向 /authorize 端點。 這是流程的互動式部分,用戶會採取動作。 在此要求中,用戶端會在 參數中 scope 指出它需要從使用者取得的許可權。 下列範例(具有可讀性的換行符)示範如何取得授權碼。 如果您要測試此 GET HTTP 要求,請使用瀏覽器。
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
| 參數 | 是必要的嗎? | 說明 |
|---|---|---|
| 租戶 | 為必填項目 | 租戶的 Azure AD B2C 名稱 |
| 政策 | 為必填項目 | 待執行的使用者流程。 請指定您在 Azure AD B2C 租戶中建立的使用者流程名稱。 例如:b2c_1_sign_in、b2c_1_sign_up 或 b2c_1_edit_profile。 |
| client_id (客戶識別碼) | 為必填項目 | 在 Azure 入口網站中指派給應用程式的應用程式識別碼。 |
| response_type(回應類型) | 為必填項目 | 回應類型,必須針對授權碼流程來加入 code。 如果您在回應類型中包括識別碼權杖 (例如 code+id_token),則會收到識別碼權杖,而在此情況下,範圍需要包括 openid。 |
| 重新導向_URI | 為必填項目 | 應用程式的重新導向 URI,您的應用程式會在此處傳送及接收驗證回應。 它必須與您在入口網站中註冊的其中一個重新導向 URI 完全相符,不過必須是 URL 編碼格式。 |
| 範圍 | 為必填項目 | 以空格分隔的範圍清單。
openid 範圍指示使用識別碼權杖形式的權限,以登入使用者及取得使用者相關資料。 對於 Web 應用程式,offline_access 範圍是選擇性的。 它表示您的應用程式需要 重新整理令牌 ,才能擴充資源的存取權。 用戶端識別碼表示簽發的權杖僅供 Azure AD B2C 註冊的用戶端使用。
https://{tenant-name}/{app-id-uri}/{scope} 指出受保護資源的權限 (例如 WEB API)。 如需詳細資訊,請參閱 要求存取令牌。 |
| 回應模式 | 推薦 | 用來將產生的授權碼傳回至應用程式的方法。 可以是 query、form_post 或 fragment。 |
| 狀態 | 推薦 | 包含在要求中的值,可以是您想要使用的任何內容字串。 通常,會使用隨機產生的唯一值來防止跨網站偽造要求攻擊。 也會先使用狀態來編碼應用程式中的使用者狀態相關資訊,再進行驗證要求。 例如,使用者所在的頁面,或正在執行的使用者流程。 |
| 提示 | 可選 | 所需的用戶互動類型。 目前唯一有效的值為 login,這會強制使用者在該要求上輸入其認證。 單一登錄不會生效。 |
| 程式碼挑戰 | 建議 / 必要 | 用來透過驗證碼交換的證明密鑰 (PKCE) 來保護授權碼授與。 如果包含 code_challenge_method,則此為必要參數。 您必須在應用程式中新增邏輯,以產生 code_verifier 和 code_challenge。
code_challenge是code_verifier的Base64 URL編碼SHA256哈希。 您會將 儲存 code_verifier 在應用程式中以供稍後使用,並連同授權要求一起傳送 code_challenge 。 如需詳細資訊,請參閱 PKCE RFC。 這現在建議用於所有應用程式類型 - 原生應用程式、SPA 和機密用戶端,例如 Web 應用程式。 |
code_challenge_method |
建議 / 必要 | 用於編碼 code_verifier 的 code_challenge 參數的方法。 這 應該是S256,但規格允許使用 plain ,如果基於某些原因,用戶端不支援SHA256。 如果您排除 code_challenge_method,但仍包含 code_challenge,則會 code_challenge 假設 為純文本。 Microsoft身分識別平台同時支援 plain 和 S256。 如需詳細資訊,請參閱 PKCE RFC。 這是 使用授權碼程序的單頁應用程式的必要條件。 |
| 登入提示 | 否 | 可用來預先填入登入頁面的登入名稱欄位。 如需詳細資訊,請參閱 預先填入登入名稱。 |
| 領域提示 | 否 | 提供 Azure AD B2C 一個提示,指出應該使用哪個社交身份識別提供者進行登入。 如果包含有效的值,使用者就會直接前往識別提供者登入頁面。 如需詳細資訊,請參閱 將登入重新導向至社交提供者。 |
| 自定義參數 | 否 | 可用於 自定義原則 的自定義參數。 例如, 動態自定義頁面內容 URI 或 索引鍵/值宣告解析程式。 |
此時,系統會要求使用者完成使用流程的任務。 這可能涉及使用者輸入其使用者名稱和密碼、使用社交帳號登入、註冊目錄或執行其他一些操作。 用戶動作取決於使用者流程的定義方式。
使用者完成使用者流程之後,Microsoft Entra ID 會將回應傳回至您的應用程式,使用您在 redirect_uri 中設定的值。 它會使用 參數中指定的 response_mode 方法。 與執行的使用者流程無關,每個用戶動作案例的回應完全相同。
使用 response_mode=query 的成功回應如下所示:
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
| 參數 | 說明 |
|---|---|
| 程式碼 | 應用程式所要求的授權碼。 應用程式可以使用授權碼來要求目標資源的存取令牌。 授權碼是短期的。 通常會在大約 10 分鐘後過期。 |
| 狀態 | 請參閱上一節表格中的完整描述。 如果要求中包含 state 參數,則回應中應該會出現相同的值。 應用程式應該確認 state 要求和回應中的值完全相同。 |
錯誤回應也可以傳送至重新導向 URI,讓應用程式可以適當地處理它們:
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
| 參數 | 說明 |
|---|---|
| 錯誤 | 錯誤碼字串,可用來分類所發生的錯誤類型。 您也可以使用字串來回應錯誤。 |
| 錯誤描述 | 可協助您識別驗證錯誤根本原因的特定錯誤訊息。 |
| 狀態 | 請參閱上表的完整描述。 如果要求中包含 state 參數,則回應中應該會出現相同的值。 應用程式應該確認 state 要求和回應中的值完全相同。 |
2.取得存取令牌
既然您已取得授權碼,您可以將 code 兌換成令牌,以使用 /token 預定資源,方法是將POST要求傳送到端點。 在 Azure AD B2C 中,您可以藉由在要求中指定範圍,像平常一樣 要求其他 API 的存取令牌 。
您也可以藉由使用應用程式的用戶端識別碼作為所需範圍來請求存取令牌,以便應用程式連接其後端 Web API(這會使該用戶端識別碼成為存取令牌所針對的「對象」):
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
| 參數 | 是必要的嗎? | 說明 |
|---|---|---|
| 租戶 | 為必填項目 | 租戶的 Azure AD B2C 名稱 |
| 政策 | 為必填項目 | 用來取得授權碼的使用者流程。 您無法在此要求中使用不同的使用者流程。 |
| client_id (客戶識別碼) | 為必填項目 | 在 Azure 入口網站中指派給應用程式的應用程式識別碼。 |
| 用戶端密鑰 | 是,在 Web Apps 中 | 在 Azure 入口網站中產生的應用程式密碼。 此流程會針對 Web 應用程式案例使用用戶端密碼,讓用戶端可以安全地儲存客戶端密碼。 針對原生應用程式(公用用戶端)案例,用戶端密碼無法安全地儲存,因此不會用於此呼叫。 如果您使用客戶端密碼,請定期變更它。 |
| grant_type (授權類型) | 為必填項目 | 授與的類型。 針對授權碼流程,授與類型必須是 authorization_code。 |
| 範圍 | 推薦 | 以空格分隔的範圍清單。 單一範圍值會向 Azure AD B2C 指出所要求的兩個許可權。 使用用戶端識別碼做為範圍,表示您的應用程式需要一個存取令牌,才能用於您自己的服務或Web API,以相同的用戶端識別元表示。 範圍 offline_access 指出您的應用程式需要重新整理令牌,才能長期存取資源。 您也可以使用 openid 範圍向 Azure AD B2C 要求 ID 令牌。 |
| 程式碼 | 為必填項目 | 您從 /authorize 端點取得的授權碼。 |
| 重新導向_URI | 為必填項目 | 您收到授權碼之應用程式的重新導向 URI。 |
| 驗證碼 | 建議 | 用來取得授權碼的相同元素 code_verifier。 如果在授權碼授與要求中使用 PKCE,則此為必要參數。 如需詳細資訊,請參閱 PKCE RFC。 |
如果您要測試此 POST HTTP 要求,您可以使用任何 HTTP 用戶端,例如 Microsoft PowerShell。
成功的令牌回應如下所示:
{
"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...",
}
| 參數 | 說明 |
|---|---|
| 提前不可 | 令牌在時間戳格式中被視為有效的時間。 |
| 令牌類型 | 令牌類型的值。 Microsoft Entra ID 唯一支援的類型是 Bearer。 |
| access_token(存取憑證) | 您要求的已簽署 JSON Web 令牌 (JWT)。 |
| 範圍 | 令牌有效的範圍。 您也可以使用範圍來快取令牌以供稍後使用。 |
| 有效期限 | 令牌有效的時間長度(以秒為單位)。 |
| 刷新令牌 | OAuth 2.0 更新權杖。 應用程式可以使用此令牌,在目前令牌到期后取得其他令牌。 刷新權杖具有長時間有效性。 您可以使用它們來保留資源長時間的存取權。 如需詳細資訊,請參閱 Azure AD B2C 令牌參考。 |
錯誤回應如下所示:
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| 參數 | 說明 |
|---|---|
| 錯誤 | 錯誤碼字串,可用來分類所發生的錯誤類型。 您也可以使用字串來回應錯誤。 |
| 錯誤描述 | 可協助您識別驗證錯誤根本原因的特定錯誤訊息。 |
3.使用令牌
既然您已成功取得存取令牌,您可以將令牌包含在標頭中 Authorization,以便在對後端 Web API 的請求中使用它。
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
4.重新整理令牌
存取令牌和標識碼令牌是短期的。 到期之後,您必須重新整理它們,才能繼續存取資源。 當您重新整理存取令牌時,Azure AD B2C 會傳回新的令牌。 重新整理的存取令牌將會更新 nbf(不早於)、iat(發行)和 exp(到期)宣告值。 所有其他聲明值都與原始發行的存取令牌相同。
若要重新整理令牌,請將另一個 POST 要求提交至 /token 端點。 這次,請提供 refresh_token ,而不是 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
| 參數 | 是必要的嗎? | 說明 |
|---|---|---|
| 租戶 | 為必填項目 | 租戶的 Azure AD B2C 名稱 |
| 政策 | 為必填項目 | 用來取得原始重新整理令牌的使用者流程。 您無法在此要求中使用不同的使用者流程。 |
| client_id (客戶識別碼) | 為必填項目 | 在 Azure 入口網站中指派給應用程式的應用程式識別碼。 |
| 用戶端密鑰 | 是,在 Web Apps 中 | 在 Azure 入口網站中產生的應用程式密碼。 此流程會針對 Web 應用程式案例使用用戶端密碼,讓用戶端可以安全地儲存客戶端密碼。 針對原生應用程式(公用用戶端)案例,用戶端密碼無法安全地儲存,因此不會用於此呼叫。 如果您使用客戶端密碼,請定期變更它。 |
| grant_type (授權類型) | 為必填項目 | 授與的類型。 對於授權碼流程的這個部分,授與類型必須是 refresh_token。 |
| 範圍 | 推薦 | 以空格分隔的範圍清單。 單一範圍值向 Microsoft Entra ID 指示正在請求的兩個許可權。 使用用戶端識別碼做為範圍,表示您的應用程式需要一個存取令牌,才能用於您自己的服務或Web API,以相同的用戶端識別元表示。 範圍 offline_access 指出您的應用程式需要重新整理令牌,才能長期存取資源。 您也可以使用 openid 範圍向 Azure AD B2C 要求 ID 令牌。 |
| 重新導向_URI | 可選 | 您收到授權碼之應用程式的重新導向 URI。 |
| 刷新令牌 | 為必填項目 | 您在流程第二階段中取得的原始刷新令牌。 |
成功的令牌回應如下所示:
{
"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...",
}
| 參數 | 說明 |
|---|---|
| 提前不可 | 令牌在時間戳格式中被視為有效的時間。 |
| 令牌類型 | 令牌類型的值。 Microsoft Entra ID 唯一支援的類型是 Bearer。 |
| access_token(存取憑證) | 您要求的已簽署 JWT。 |
| 範圍 | 令牌有效的範圍。 您也可以使用範圍來快取令牌,以供稍後使用。 |
| 有效期限 | 令牌有效的時間長度(以秒為單位)。 |
| 刷新令牌 | OAuth 2.0 更新權杖。 應用程式可以使用此令牌,在目前令牌到期后取得其他令牌。 重新整理令牌會長期存在,可用來保留資源長時間的存取權。 如需詳細資訊,請參閱 Azure AD B2C 令牌參考。 |
錯誤回應如下所示:
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| 參數 | 說明 |
|---|---|
| 錯誤 | 錯誤碼字串,可用來分類發生的錯誤類型。 您也可以使用字串來回應錯誤。 |
| 錯誤描述 | 可協助您識別驗證錯誤根本原因的特定錯誤訊息。 |
使用您自己的 Azure AD B2C 目錄
若要自行嘗試這些要求,請完成下列步驟。 以您自己的值取代本文中使用的範例值。
- 建立 Azure AD B2C 目錄。 在請求中使用目錄的名稱。
- 建立應用程式 以取得應用程式識別碼和重新導向 URI。 在您的應用程式中包含原生用戶端。
- 建立您的使用者流程 以取得您的使用者流程名稱。