這很重要
自 2025 年 5 月 1 日起，Azure AD B2C 將不再可供新客戶購買。 在我們的常見問題中深入瞭解。
Azure Active Directory B2C （Azure AD B2C） 藉由支援兩種業界標準通訊協定，為您的應用程式提供身分識別即服務：OpenID Connect 和 OAuth 2.0。 此服務符合標準，但這些通訊協定的任何兩個實作可能會有細微的差異。
如果您直接傳送和處理 HTTP 要求，而不是使用開放原始碼連結庫來撰寫程式代碼，本指南中的資訊就很有用。 建議您先閱讀此頁面，再深入瞭解每個特定通訊協定的詳細數據。 但是，如果您已經熟悉 Azure AD B2C，您可以直接前往 通訊協議參考指南。
基本知識
使用 Azure AD B2C 的每個應用程式都必須在 Azure 入口網站的 B2C 目錄中註冊。 應用程式註冊程式會收集並指派一些值給您的應用程式：
唯一識別應用程式的 應用程式識別碼。
重新導向 URI 或 套件識別碼 ，可用來將響應導向回您的應用程式。
其他幾個案例特定值。 如需詳細資訊，請 瞭解如何註冊您的應用程式。
註冊應用程式之後，它會透過將要求傳送至端點來與 Azure AD B2C 通訊：
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token
如果您使用自訂網域，請在端點中用自訂網域（例如 {tenant}.b2clogin.com）取代contoso.com。
在幾乎所有的 OAuth 和 OpenID Connect 流程中，有四方參與交換：
授權伺服器是 Azure AD B2C 端點。 它會安全地處理與使用者資訊和存取相關的任何專案。 它也會處理流程中合作對象之間的信任關係。 其負責驗證使用者的身分識別、授與和撤銷資源的存取權，以及發行令牌。 也稱為身分識別提供者。
資源擁有者通常是使用者。 擁有資料的主體有權允許第三方存取該資料或資源。
OAuth 用戶端是您的應用程式。 它透過其應用程式識別碼來進行識別。 通常是終端使用者互動的一方。 它也會向授權伺服器要求令牌。 資源擁有者必須授與用戶端存取資源的許可權。
資源伺服器是資源或數據所在的位置。 它會信任授權伺服器，以安全地驗證和授權 OAuth 用戶端。 它也會使用持有人存取令牌來確保可以授與資源的存取權。
政策和使用者流程
Azure AD B2C 透過引進原則來擴充標準 OAuth 2.0 和 OpenID Connect 通訊協定。 這些可讓 Azure AD B2C 執行比簡單的驗證和授權還要多。
為了協助您設定最常見的身分識別工作，Azure AD B2C 入口網站包含預先定義的可設定原則，稱為 使用者流程。 使用者流程會完整描述取用者身分識別體驗，包括註冊、登入和配置文件編輯。 使用者流程可以在系統管理UI中定義。 您可以在 HTTP 驗證要求中使用特殊查詢參數來執行它們。
原則和使用者流程不是 OAuth 2.0 和 OpenID Connect 的標準功能，因此您應該花點時間了解它們。 如需詳細資訊，請參閱 Azure AD B2C 使用者流程參考指南。
代幣
OAuth 2.0 和 OpenID Connect 的 Azure AD B2C 實作會廣泛使用持有人令牌，包括以 JSON Web 令牌表示的持有人令牌（JWT）。 持有人令牌是輕量型安全性令牌，可授與受保護資源的「持有人」存取權。
持有人是任何能夠出示令牌的一方。 Azure AD B2C 必須先驗證一方，才能接收持有者令牌。 但是，如果未採取必要的步驟來保護傳輸和記憶體中的令牌，則可以被非預期對象攔截和使用。
某些安全性令牌具有內建機制，可防止未經授權的第三方使用這些令牌，但持有者令牌沒有此機制。 它們必須在安全通道中傳輸，例如傳輸層安全性 （HTTPS）。
如果在安全通道外部傳輸持有人令牌，惡意方可以使用中間人攻擊來取得令牌，並用它來取得受保護資源的未經授權存取權。 儲存或快取持有人令牌以供稍後使用時，適用相同的安全性原則。 請務必確定您的應用程式會以安全的方式傳輸和儲存持有人令牌。
如需額外的持有人令牌安全性考慮，請參閱 RFC 6750 第 5 節。
如需 Azure AD B2C 中使用的不同令牌類型詳細資訊，請參閱 Azure AD B2C 令牌參考。
協定
當您準備好檢閱一些範例要求時，您可以從下列其中一個教學課程開始。 每個都對應至特定的驗證案例。 如果您需要判斷哪一個流程適合您，請查看 您可以使用 Azure AD B2C 建置的應用程式類型。