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

Azure Active Directory B2C (Azure AD B2C) 支援各種新式應用程式結構的驗證。 全部都以業界標準通訊協定 OAuth 2.0OpenID 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 伺服器且透過瀏覽器存取的 Web 應用程式 (包括 .NET、PHP、Java、Ruby、Python 及 Node.js),Azure AD B2C 支援使用 OpenID Connect 的所有使用者體驗。 在 OpenID Connect 的 Azure AD B2C 實作中,您的 Web 應用程式會發出驗證要求給Microsoft Entra識別碼來起始使用者體驗。 要求的結果是 id_token。 這個安全性權杖代表使用者的身分識別。 它也以宣告形式提供使用者的相關資訊:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

請參閱 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 所需的「存取」權杖,交換授權碼。 此外,其會傳回重新整理權杖,以代表使用者提供長期的資源存取權,而不需要與使用者互動。

建議採用此方法。 具備有限存留期的重新整理權杖可協助您的應用程式適應新式瀏覽器 Cookie 隱私權限制,例如 Safari ITP。

若要利用此流程,您的應用程式可以使用支援此流程的驗證程式庫,例如 MSAL.js 2.x

Single-page applications-auth

隱含授與流程

某些程式庫,例如 MSAL.js 1.x,僅支援隱含授與流程,或者系統會實作您的應用程式,以使用隱含流程。 在這些案例中,Azure AD B2C 會支援 OAuth 2.0 隱含流程。 隱含授與流程可讓應用程式取得識別碼存取權杖。 不同於授權碼流程,隱含授與流程不會傳回「重新整理權杖」。

不建議使用此方法。

此驗證流程不包含使用跨平台 JavaScript 架構 (例如 Electron 和 React-Native) 的應用程式案例。 這些案例需要進一步的功能來與原生平台互動。

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 應用程式呼叫 Web API 的完整流程範例:

  1. Web 應用程式會執行原則,而且使用者完成了使用者體驗。
  2. Azure AD B2C 會將 (OpenID Connect) id_token 和授權碼傳回給瀏覽器。
  3. 瀏覽器會將 id_token 和授權碼張貼到重新導向 URI。
  4. Web 伺服器會驗證 id_token 並設定工作階段 cookie。
  5. Web 伺服器透過向 Azure AD B2C 提供授權碼、應用程式用戶端識別碼和用戶端認證,來向 Azure AD B2C 要求 access_token
  6. 系統會將 access_tokenrefresh_token 傳回給 Web 伺服器。
  7. 使用授權標頭中的 access_token 可呼叫 Web API。
  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_codeauthorization_code 代表應用程式有權代表目前登入的使用者來呼叫後端服務。 然後應用程式就可在背景中以 authorization_code 交換 access_tokenrefresh_token。 應用程式可以在 HTTP 要求中使用 access_token 來向後端 Web API 進行驗證。 它也可以使用 refresh_token 來取得新的 access_token (當舊的已過期時)。

精靈/伺服器端應用程式

如果應用程式含有長時間執行的處理序或不需要使用者操作,也仍然需要有存取受保護資源的方法,例如 Web API。 這些應用程式可以使用其身分識別 (而非使用者的委派身分識別),以及使用 OAuth 2.0 用戶端認證流程,以驗證及取得權杖。 用戶端認證流程與代理流程不同,代理流程不應用於伺服器對伺服器的驗證。

針對 Azure AD B2C,OAuth 2.0 用戶端認證流程目前處於公開預覽狀態。 不過,您可以使用 microsoft Graph 應用程式或您自己的應用程式,使用Microsoft Entra識別碼和Microsoft 身分識別平臺 /token 端點 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 Graph API 這類 Microsoft 線上服務。

使用 OAuth 2.0 JWT 持有人認證授與可支援此鏈結的 Web API 案例,亦稱為代理者流程。 不過,Azure AD B2C 目前未實作代理者流程。

後續步驟

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