共用方式為

可在 Active Directory B2C 中使用的應用程式類型

這很重要

自 2025 年 5 月 1 日起，Azure AD B2C 將不再可供新客戶購買。 在我們的常見問題中深入瞭解。

Azure Active Directory B2C （Azure AD B2C） 支援各種新式應用程式架構的驗證。 它們全都以業界標準通訊協定 OAuth 2.0 或 OpenID Connect 為基礎。 本文說明您可以建置的應用程式類型，與偏好的語言或平台無關。 它也可協助您先瞭解高階案例，再開始建置應用程式。

使用 Azure AD B2C 的每個應用程式都必須使用 Azure 入口網站 在您的 Azure AD B2C 租戶中註冊。 應用程式註冊程式會收集並指派值，例如：

  • 一個能唯一識別應用程式的 應用程式識別碼。
  • 可用來將回應導向回您應用程式的 回復URL 。

傳送至 Azure AD B2C 的每個要求都會指定 使用者流程 （內建原則）或控制 Azure AD B2C 行為的 自定義原則 。 這兩種原則類型都可讓您建立一組高度自定義的用戶體驗。

每個應用程式互動都會遵循類似的高階模式：

  1. 應用程式會將使用者導向 v2.0 端點，以執行 原則。
  2. 用戶根據政策定義完成政策。
  3. 應用程式會從 v2.0 端點接收安全性令牌。
  4. 應用程式會使用安全性令牌來存取受保護的資訊或受保護的資源。
  5. 資源伺服器會驗證安全性令牌，以確認可以授與存取權。
  6. 應用程式會定期重新整理安全性令牌。

這些步驟可能會根據您要建置的應用程式類型稍有不同。

Web 應用程式

對於裝載於網頁伺服器上並透過瀏覽器存取的 Web 應用程式（包括 .NET、PHP、Java、Ruby、Python 和 Node.js），Azure AD B2C 支援 OpenID Connect ，以取得所有用戶體驗。 在 OpenID Connect 的 Azure AD B2C 實作中，您的 Web 應用程式會發出驗證要求以向 Microsoft Entra ID 起始用戶體驗。 要求的結果為 id_token。 此安全性令牌代表使用者的身分識別。 它還會以聲明形式提供使用者的相關資訊：

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

深入瞭解 Azure AD B2C 令牌參考中應用程式可用的令牌和宣告類型。

在 Web 應用程式中，原則的每個 執行都會採用 下列高階步驟：

  1. 用戶流覽至 Web 應用程式。
  2. Web 應用程式會將使用者重新導向至 Azure AD B2C，指出要執行的原則。
  3. 使用者完成政策。
  4. Azure AD B2C 會將 id_token 傳回至瀏覽器。
  5. id_token會被發送至重定向 URI。
  6. id_token已驗證 ，並設定會話 Cookie。
  7. 安全頁面會傳回給使用者。

id_token使用從 Microsoft Entra 識別元收到的公開簽署金鑰進行驗證，足以驗證使用者的身分識別。 此過程也會設定會話 Cookie，以便在後續頁面要求中識別使用者。

若要查看此案例的運作情形，請嘗試我們的 用戶入門一節中的其中一個 Web 應用程式登入程式碼範例。

除了促進簡單登入之外，Web 應用程式可能也需要存取後端Web服務。 在此情況下，Web 應用程式可以執行稍微不同的 OpenID Connect 流程 ，並使用授權碼和重新整理令牌來取得令牌。 此案例描述於下列 Web API 一節中。

單頁應用程式

許多新式 Web 應用程式都是建置為用戶端單頁應用程式（“SPA”）。 開發人員會使用 JavaScript 或 SPA 架構來撰寫它們，例如 Angular、Vue 或 React。 這些應用程式會在網頁瀏覽器上執行，且具有與傳統伺服器端 Web 應用程式不同的驗證特性。

Azure AD B2C 提供 兩 個選項，可讓單頁應用程式登入使用者，並取得令牌以存取後端服務或 Web API：

授權碼流程 （使用 PKCE）

OAuth 2.0 授權碼流程（含 PKCE） 可讓應用程式交換 標識元 令牌的授權碼，以代表呼叫受保護 API 所需的已驗證使用者和 存取 令牌。 此外，它會傳回 Refresh 令牌，代表使用者提供資源的長期存取權，而不需要與這些用戶互動。

我們建議使用此方法。 擁有有限的存留期重新整理令牌可協助您的應用程式適應 新式瀏覽器 Cookie 隱私權限制，例如 Safari ITP。

要利用此流程，您的應用程式可以使用支援它的身份驗證庫，例如 MSAL.js 2.x。

單頁應用程式驗證

隱含授與流程

某些庫（如 MSAL.js 1.x）僅支援 隱式授權流 ，或者您的應用程式被實現為使用隱式流。 在這些情況下，Azure AD B2C 支援 OAuth 2.0 隱含流程。 隱含授與流程可讓應用程式取得 標識碼 和 存取 令牌。 不同於授權碼流程，隱式授權流程不會傳回 刷新令牌。

此驗證流程不包含使用電子和 React-Native 等跨平臺 JavaScript 架構的應用程式案例。 這些案例需要進一步的功能，以便與原生平台互動。

警告

Microsoft 建議您「不要」使用隱含授與流程。 支援 SPA 的建議方式是 OAuth 2.0 授權碼流程（使用 PKCE）。 某流程的些設定在應用程式中需要非常高的信任度，而且帶有未在其他流程中出現的風險。 您應該只在其他更安全的流程都無法使用時，才使用此流程。 如需詳細資訊，請參閱隱含授與流程的安全性考慮。

Web API

您可以使用 Azure AD B2C 來保護 Web 服務，例如應用程式的 RESTful Web API。 Web API 可以使用 OAuth 2.0 透過使用令牌驗證連入 HTTP 要求來保護其數據。 Web API 的呼叫端會在 HTTP 要求的授權標頭中附加令牌：

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
Accept: application/json
...

然後，Web API 可以使用令牌來驗證 API 呼叫端的身分識別，並從令牌中編碼的宣告擷取呼叫者的相關信息。 深入瞭解 Azure AD B2C 令牌參考中應用程式可用的令牌和宣告類型。

Web API 可以從許多類型的用戶端接收令牌，包括 Web 應用程式、桌面和行動應用程式、單頁應用程式、伺服器端精靈和其他 Web API。 以下是呼叫 Web API 之 Web 應用程式的完整流程範例：

  1. Web 應用程式會執行原則，而使用者完成用戶體驗。
  2. Azure AD B2C 會將 （OpenID Connect） id_token 和授權碼傳回給瀏覽器。
  3. 瀏覽器會將 id_token 和授權碼張貼至重新導向 URI。
  4. 網頁伺服器會驗證id_token並設定會話 cookie。
  5. Web 伺服器提供授權碼、應用程式用戶端識別碼和客戶端認證，以請求 Azure AD B2C access_token。
  6. access_token 和 refresh_token 會傳回至網頁伺服器。
  7. Web API 會以授權標頭中的 access_token 進行呼叫。
  8. Web API 會驗證令牌。
  9. 安全數據會傳回至 Web 應用程式。

若要深入瞭解授權碼、重新整理令牌，以及取得令牌的步驟，請閱讀 OAuth 2.0 通訊協定。

若要瞭解如何使用 Azure AD B2C 保護 Web API，請參閱用戶 入門一節中的 Web API 教學課程。

行動與原生應用程式

安裝在行動裝置和傳統型應用程式等裝置上的應用程式，通常需要代表使用者存取後端服務或 Web API。 您可以將自定義的身分識別管理體驗新增至原生應用程式，並使用 Azure AD B2C 和 OAuth 2.0 授權碼流程安全地呼叫後端服務。

在此流程中，應用程式會執行 原則 ，並在使用者完成原則之後，從 Microsoft Entra 識別碼接收 authorization_code 。 authorization_code代表應用程式代表目前登入的使用者呼叫後端服務的許可權。 然後，應用程式可以在背景中交換 authorization_code 為access_token 和 refresh_token。 應用程式可以使用 access_token 向 HTTP 要求中的後端 Web API 進行驗證。 當較舊的到期時，它也可以使用 refresh_token 來取得新的 access_token 。

精靈/伺服器端應用程式

包含長時間執行進程或在沒有用戶狀態的情況下運作的應用程式，也需要存取受保護的資源，例如 Web API。 這些應用程式可以使用其身分識別來驗證和取得令牌（而不是使用者的委派身分識別），以及使用 OAuth 2.0 用戶端認證流程。 客戶端認證流程與代理流程不同，而代理流程不應該用於伺服器對伺服器驗證。

針對 Azure AD B2C，OAuth 2.0 用戶端認證流程 目前處於公開預覽狀態。 不過，您可以針對 /token或您自己的應用程式，使用 Microsoft Entra ID 和 Microsoft 身分識別平臺https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token端點 （） 來設定客戶端認證流程。 如需詳細資訊，請參閱 Microsoft Entra 令牌參考 文章。

不支援的應用程式類型

Web API 鏈結（代理流程）

許多架構都包含需要呼叫另一個下游Web API的Web API，其中兩者都受到 Azure AD B2C 保護。 此案例常見於具有 Web API 後端的原生用戶端，並呼叫Microsoft在線服務，例如 Microsoft Graph API。

您可以使用 OAuth 2.0 JWT 持有人憑證授與，支援此連鎖的 Web API 場景，也稱為代理授與流程。 不過，代理流程目前並未在 Azure AD B2C 中實作。

後續步驟

深入瞭解 Azure Active Directory B2C 中使用者流程所提供的內建原則。

  • Last updated on