重要
自 2025 年 5 月 1 日起，Azure AD B2C 將不再可供新客戶購買。 在我們的常見問題中深入瞭解。
許多新式應用程式都有單頁應用程式 （SPA） 前端，主要以 JavaScript 撰寫。 應用程式通常會使用 React、Angular 或 Vue.js等架構來撰寫。 主要在瀏覽器中執行的 SPA 和其他 JavaScript 應用程式有一些額外的驗證挑戰：
這些應用程式的安全性特性與傳統伺服器型 Web 應用程式不同。
許多授權伺服器和識別提供者都不支援跨原始來源資源分享 （CORS） 要求。
全頁瀏覽器會從應用程式重新導向，對用戶體驗有侵入性。
警告
Microsoft 建議您「不要」使用隱含授與流程。 支援 SPA 的建議方式是 OAuth 2.0 授權碼流程（使用 PKCE）。 某流程的些設定在應用程式中需要非常高的信任度，而且帶有未在其他流程中出現的風險。 您應該只在其他更安全的流程都無法使用時，才使用此流程。 如需詳細資訊，請參閱隱含授與流程的安全性考慮。
某些架構，例如 MSAL.js 1.x，只支援隱含授與流程。 在這些情況下，Azure Active Directory B2C （Azure AD B2C） 支援 OAuth 2.0 授權隱含授與流程。 此流程會在 OAuth 2.0 規格的第 4.2 節中說明。 在隱含流程中，應用程式會直接從 Azure AD B2C 授權端點接收令牌，而不需要任何伺服器對伺服器交換。 所有驗證邏輯和會話處理全部在JavaScript用戶端中完成，透過頁面重定向或彈出視窗進行。
Azure AD B2C 會將標準 OAuth 2.0 隱含流程延伸至不僅限於簡單的驗證和授權。 Azure AD B2C 引進 原則參數。 使用原則參數，您可以使用 OAuth 2.0 將原則新增至您的應用程式，例如註冊、登入和配置檔管理使用者流程。 在本文中的 HTTP 要求範例中，我們會使用 {tenant}.onmicrosoft.com 來說明。 如果您有租用戶的名稱，請將{tenant}取代為租用戶的名稱。 此外，您必須 建立使用者流程。
我們使用下圖來說明隱含登入流程。 本文稍後會詳細說明每個步驟。
當您的 Web 應用程式需要驗證使用者並執行使用者流程時，它會將使用者導向 Azure AD B2C 的 /authorize 端點。 用戶會根據用戶使用流程採取動作。
在此請求中，客戶端指出它需要從 scope 參數中獲取使用者的許可權，以及要執行的使用者流程。 若要瞭解要求的運作方式，請嘗試將要求貼入瀏覽器並加以執行。 替換為：
將
{tenant}替換為您的 Azure AD B2C 租用戶名稱。00001111-aaaa-2222-bbbb-3333cccc4444具有您在租用戶中註冊之應用程式的應用程式識別碼。{policy}使用您在租戶中建立的原則名稱，例如b2c_1_sign_in。
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
下表說明 HTTP GET 要求中的參數。
| 參數 | 為必填項目 | 說明 |
|---|---|---|
| 租戶 | 是的 | 租戶的 Azure AD B2C 名稱 |
| 政策 | 是的 | 您要執行的使用者流程名稱。 請指定您在 Azure AD B2C 租戶中建立的使用者流程名稱。 例如：b2c_1_sign_in、b2c_1_sign_up 或 b2c_1_edit_profile。 |
| client_id (客戶識別碼) | 是的 | Azure 入口網站指派給應用程式的應用程式識別碼。 |
| response_type（回應類型） | 是的 | 必須包含 id_token 才能進行 OpenID Connect 登入。 它也可以包含回應類型 token。 如果您使用 token，您的應用程式可以立即從授權端點接收存取令牌，而不需對授權端點提出第二個要求。 如果您使用 token 回應類型， scope 參數必須包含一個範圍，指出要發行令牌的資源。 |
| 重新導向_URI | 否 | 應用程式的重新導向 URI，您的應用程式可在此傳送及接收驗證回應。 它必須完全符合您在入口網站中新增至已註冊應用程式的其中一個重新導向 URI，不同之處在於它必須經過 URL 編碼。 |
| 回應模式 | 否 | 指定要用來將產生的令牌傳回應用程式的方法。 針對隱含流程，請使用 fragment。 |
| 範圍 | 是的 | 以空格分隔的範圍清單。 單一範圍值向 Microsoft Entra ID 指示正在請求的兩個許可權。
openid 範圍指示使用識別碼權杖形式的權限，以登入使用者及取得使用者相關資料。 Web offline_access 應用程式的範圍是選擇性的。 它表示您的應用程式需要重新整理令牌，才能長期存取資源。 |
| 狀態 | 否 | 在請求中包含的一個值，也會在令牌回應中被返回。 它可以是您想要使用之任何內容的字串。 通常，會使用隨機產生的唯一值，以防止跨網站要求偽造攻擊。 狀態也可用來在驗證要求發生之前，在應用程式中編碼用戶狀態的相關信息，例如使用者開啟的頁面，或正在執行的使用者流程。 |
| 隨機數 | 是的 | 要求中包含的值（由應用程式生成），在生成的 ID 憑證中包含為聲明。 然後，應用程式可以驗證此值，以減輕令牌重播攻擊。 值通常是隨機化的唯一字串，可用來識別要求的來源。 |
| 提示 | 否 | 所需的用戶互動類型。 目前唯一有效的值為 login。 此參數會強制使用者在該要求上輸入其認證。 單獨的 Sign-On 無法生效。 |
這是流程的互動式部分。 系統會要求使用者完成政策的工作流程。 使用者可能必須輸入其使用者名稱和密碼；使用社交帳號登入；註冊本機帳戶；或執行其他若干步驟。 用戶動作取決於使用者流程的定義方式。
使用者完成使用者流程之後，Azure AD B2C 會透過 redirect_uri傳回應用程式的回應。 它會使用 參數中指定的 response_mode 方法。 與執行的使用者流程無關，每個用戶動作案例的回應完全相同。
使用 response_mode=fragment 和 response_type=id_token+token 的回應成功範例如下，以便於閱讀的換行符號：
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| 參數 | 說明 |
|---|---|
| access_token（存取憑證） | Azure AD B2C 所要求的應用程式存取令牌。 |
| 令牌類型 | 令牌類型的值。 Azure AD B2C 支援的唯一類型是 Bearer。 |
| 有效期限 | 存取令牌有效的時間長度（以秒為單位）。 |
| 範圍 | 令牌有效的範圍。 您也可以使用範圍來快取令牌以供稍後使用。 |
| id_token（驗證令牌） | 應用程式所要求的識別碼權杖。 您可以使用識別碼權杖來確認使用者的身分識別，然後開始與使用者的工作階段。 如需標識符令牌及其內容的詳細資訊，請參閱 Azure AD B2C 令牌參考。 |
| 狀態 | 如果要求中包含 state 參數，則回應中應該會出現相同的值。 應用程式應該確認 state 要求和回應中的值完全相同。 |
錯誤回應也可以傳送至重新導向 URI，讓應用程式可以適當地處理它們：
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| 參數 | 說明 |
|---|---|
| 錯誤 | 用來分類所發生錯誤類型的程序代碼。 |
| 錯誤描述 | 可協助您識別驗證錯誤根本原因的特定錯誤訊息。 |
| 狀態 | 如果要求中包含 state 參數，則回應中應該會出現相同的值。 應用程式應該確認 state 要求和回應中的值完全相同。 |
接收標識碼令牌不足以驗證使用者。 驗證 ID Token 的簽章，並根據您的應用程式需求驗證令牌中的聲明。 Azure AD B2C 使用 JSON Web 令牌 （JWT） 和公鑰密碼編譯來簽署令牌，並確認其有效。
根據您偏好使用的語言，許多開放原始碼連結庫都可用於驗證 JWT。 請考慮探索可用的開放原始碼連結庫，而不是實作您自己的驗證邏輯。 您可以使用本文中的資訊來協助您瞭解如何正確使用這些連結庫。
Azure AD B2C 具有 OpenID Connect 元數據端點。 應用程式可以使用端點在運行時間擷取 Azure AD B2C 的相關信息。 此資訊包括端點、令牌內容和令牌簽署金鑰。 Azure AD B2C 租使用者中的每個使用者流程都有 JSON 元數據檔。 例如，在租戶中名為 b2c_1_sign_in 的使用者流程的元數據文檔位於：
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
此組態檔的其中一個屬性是 jwks_uri。 相同使用者流程的數值為：
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
若要判斷用來簽署識別碼令牌的使用者流程（以及從何處擷取元數據），您可以使用下列任一選項：
使用者流程名稱包含在
acr的id_token宣告中。 如需有關如何從 ID 令牌剖析宣告的詳細資訊，請參閱 Azure AD B2C 令牌參考。當您發出要求時，將使用者流程編碼在參數
state的值中。 然後，將state參數解碼，以判斷是哪個使用者流程被使用。
從 OpenID Connect 元數據端點取得元數據檔之後，您可以使用 RSA-256 公鑰（位於此端點）來驗證標識元令牌的簽章。 在任意時刻，此端點可能會列出多個密鑰，每個密鑰都由 kid所識別。 的 id_token 標頭也包含 kid 宣告。 它指出這些金鑰中的哪一個用來簽署標識元令牌。 如需詳細資訊，包括了解 驗證令牌，請參閱 Azure AD B2C 令牌參考。
驗證 ID 令牌的簽章之後，有數個聲明需要驗證。 例如：
驗證
nonce宣告以防止令牌重播攻擊。 其值應該是您在登入要求中指定的值。aud驗證宣告，以確保已針對您的應用程式發出標識元令牌。 其值應該是應用程式的應用程式識別碼。驗證
iat和exp宣告，以確保身份令牌尚未過期。
在 OpenID Connect核心規格中，會詳細說明您應該執行的數個驗證。根據您的案例，您可能也想要驗證其他宣告。 一些常見的驗證包括：
確保使用者或組織已註冊應用程式。
確保使用者具有適當的授權和許可權。
確保已達到特定的驗證強度，例如使用 Microsoft Entra 多重要素驗證。
如需有關 ID 標識碼中宣告的詳細資訊，請參閱 Azure AD B2C 令牌參考。
驗證標識元令牌之後，您就可以開始與用戶進行會話。 在您的應用程式中，使用 ID 令牌中的宣告來取得使用者的相關資訊。 此資訊可用於顯示、記錄、授權等。
如果 Web 應用程式唯一需要執行的動作是執行使用者流程，您可以略過接下來的幾節。 下列各節中的資訊僅適用於需要對 Azure AD B2C 本身所保護之 Web API 進行已驗證呼叫的 Web 應用程式。
既然您已將使用者登入 SPA，您可以取得存取令牌，以呼叫受Microsoft Entra ID 保護的 Web API。 即使您已經使用 token 回應類型收到令牌，您也可以使用此方法取得其他資源的令牌，而不重新導向使用者再次登入。
在一般 Web 應用程式流程中，您會對 /token 端點提出要求。 不過，端點不支援 CORS 要求，因此進行 AJAX 呼叫以取得重新整理令牌不是選項。 相反地，您可以在隱藏的 HTML iframe 元素中使用隱含的流程來取得新的令牌以用於其他 Web API。 以下是一個範例：為了提高可讀性，使用換行。
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| 參數 | 是必要的嗎? | 說明 |
|---|---|---|
| 租戶 | 為必填項目 | 租戶的 Azure AD B2C 名稱 |
| 政策 | 為必填項目 | 待執行的使用者流程。 請指定您在 Azure AD B2C 租戶中建立的使用者流程名稱。 例如：b2c_1_sign_in、b2c_1_sign_up 或 b2c_1_edit_profile。 |
| client_id (客戶識別碼) | 為必填項目 | 在 Azure 入口網站中指派給應用程式的應用程式識別碼。 |
| response_type（回應類型） | 為必填項目 | 必須包含 id_token 來進行 OpenID Connect 登入。 它也可能包含回應類型 token。 如果您在這裡使用 token ，您的應用程式可以立即從授權端點接收存取令牌，而不需對授權端點提出第二個要求。 如果您使用 token 回應類型， scope 參數必須包含一個範圍，指出要發行令牌的資源。 |
| 重新導向_URI | 推薦 | 應用程式的重新導向 URI，您的應用程式可在此傳送及接收驗證回應。 它必須與您在入口網站中註冊的其中一個重新導向 URI 完全相符，不過必須是 URL 編碼格式。 |
| 範圍 | 為必填項目 | 以空格分隔的範圍清單。 若要取得令牌，請包含目標資源所需的所有範圍。 |
| 回應模式 | 推薦 | 指定用來將產生的令牌傳送回應用程式的方法。 針對隱含流程，請使用 fragment。 另外可以指定兩種模式，query 和 form_post，但無法在隱含流程中工作。 |
| 狀態 | 推薦 | 令牌回應中傳回的要求中包含的值。 它可以是您想要使用之任何內容的字串。 通常，會使用隨機產生的唯一值，以防止跨網站要求偽造攻擊。 也會先使用狀態來編碼應用程式中的使用者狀態相關資訊，再進行驗證要求。 例如，用戶當時所在的頁面或視圖。 |
| 隨機數 | 為必填項目 | 要求中包含的值是應用程式產生的，並作為宣告包含在結果的 ID 令牌中。 然後，應用程式可以驗證此值，以減輕令牌重播攻擊。 值通常是隨機化的唯一字串，可識別要求的來源。 |
| 提示 | 為必填項目 | 若要重新整理並取得隱藏 iframe 中的令牌，請使用 prompt=none 確保 iframe 不會卡在登入頁面上，並立即傳回。 |
| 登入提示 | 為必填項目 | 若要在隱藏的 iframe 中重新取得和刷新令牌，請在此提示中包含使用者名稱，以區分使用者在特定時間內可能有的多個工作階段。 您可以使用 preferred_username 宣告，從先前的登入中擷取用戶名稱（需要 profile 範圍才能接收 preferred_username 宣告）。 |
| 領域提示 | 為必填項目 | 可以是 consumers 或 organizations。 若要在隱藏的 iframe 中刷新和取得令牌，請在要求中包含 domain_hint 值。 從先前登入的身份令牌中擷取宣告內容，以判斷要使用的值（需要tid範圍才能接收profile宣告內容）。
tid如果宣告值為 9188040d-6c67-4c5b-b112-36a304b66dad，請使用 domain_hint=consumers。 否則，請使用 domain_hint=organizations。 |
藉由設定 prompt=none 參數，此要求會立即成功或失敗，並返回您的應用程式。 使用 參數中指定的 response_mode 方法，透過重新導向 URI 將成功的回應傳送至您的應用程式。
使用 response_mode=fragment 的成功回應看起來像下列範例：
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| 參數 | 說明 |
|---|---|
| access_token（存取憑證） | 應用程式所要求的令牌。 |
| 令牌類型 | 令牌類型一律為 Bearer。 |
| 狀態 | 如果要求中包含 state 參數，則回應中應該會出現相同的值。 應用程式應該確認 state 要求和回應中的值完全相同。 |
| 有效期限 | 存取權杖的有效時間 (以秒為單位)。 |
| 範圍 | 存取令牌有效的範圍。 |
錯誤回應也可以傳送至重新導向 URI，讓應用程式可以適當地處理它們。 針對 prompt=none，預期的錯誤看起來像下列範例：
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| 參數 | 說明 |
|---|---|
| 錯誤 | 錯誤碼字串，可用來分類發生的錯誤類型。 您也可以使用字串來回應錯誤。 |
| 錯誤描述 | 可協助您識別驗證錯誤根本原因的特定錯誤訊息。 |
如果您在 iframe 要求中收到此錯誤，使用者必須再次以互動方式登入以擷取新的權杖。
標識元令牌和存取令牌都會在短時間內到期。 您的應用程式必須準備好定期重新整理這些令牌。 隱含流程不允許您因為安全性原因而取得重新整理令牌。 若要重新整理任一類型的令牌，請在隱藏的 HTML iframe 元素中使用隱含流程。 在授權要求中包含 prompt=none 參數。 若要接收新的 id_token 值，請務必使用 response_type=id_token 和 scope=openid，以及一個 nonce 參數。
當您想要將使用者註銷應用程式時，請將使用者重新導向至 Azure AD B2C 的登出端點。 然後，您可以在應用程式中結束使用者會話。 如果您未將使用者重新導向，他們可能無法重新驗證至您的應用程式，而不需要再次輸入其認證，因為它們具有與 Azure AD B2C 的有效單一 Sign-On 工作階段。
您可以直接將使用者重新導向至 end_session_endpoint 與 驗證識別元令牌中所述之相同 OpenID Connect 元資料檔中所列的 。 例如：
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
| 參數 | 為必填項目 | 說明 |
|---|---|---|
| 租戶 | 是的 | Azure AD B2C 租戶的名稱。 |
| 政策 | 是的 | 用於將使用者登出您的應用程式的使用者流程。 這必須是應用程式用來讓使用者登入的相同操作流程。 |
| 登出後重導向位址 (post_logout_redirect_uri) | 否 | 成功登出後，使用者應該被重新導向至的URL。如果未包含，Azure AD B2C 會向使用者顯示一般訊息。 |
| 狀態 | 否 | 如果要求中包含 state 參數，則回應中應該會出現相同的值。 應用程式應該確認 state 要求和回應中的值完全相同。 |
注意
將用戶導向至 end_session_endpoint 可以清除部分使用者的 Single Sign-On 狀態與 Azure AD B2C 一起。 不過，它不會將使用者註銷使用者的社交識別提供者會話。 如果使用者在後續登入期間選取相同的識別提供者，則會重新驗證使用者，而不需要輸入其認證。 例如，如果使用者想要註銷您的 Azure AD B2C 應用程式，不一定表示他們想要完全註銷其 Facebook 帳戶。 不過，針對本地帳戶，使用者的會話將正確結束。
請參閱程式代碼範例： 在 JavaScript SPA 中使用 Azure AD B2C 登入。