Azure AD B2C：驗證通訊協定
Azure Active Directory B2C (Azure AD B2C) 支援 OpenID Connect 與 OAuth 2.0 兩種業界標準通訊協定，為您的 app 提供身分識別即服務。 這是符合標準的服務，但是這些通訊協定在任兩個實作之間仍會有些微差異。
若您藉由直接傳送和處理 HTTP 要求來撰寫程式碼，而非使用開放原始碼程式庫，則本指南中的資訊很有用。 建議您在深入探討每個特定通訊協定的詳細資料之前，先閱讀此頁面。 但若您已經熟悉 Azure AD B2C，您可以直接閱讀通訊協定參考指南。
基本知識
使用 Azure AD B2C 的每個 app 都必須在 Azure 入口網站內您的 B2C 目錄中註冊。 App 註冊處理序會收集與指派一些值給您的 app：
可唯一識別應用程式的 應用程式識別碼 。
可將回應導回至應用程式的重新導向 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 建置的應用程式類型。