Microsoft 身分識別平臺通訊協定Microsoft identity platform protocols

適用于身分識別即服務的 Microsoft 身分識別平臺端點, 具有業界標準通訊協定、OpenID Connect 和 OAuth 2.0。The Microsoft identity platform endpoint for identity-as-a-service with industry standard protocols, OpenID Connect and OAuth 2.0. 雖然這是符合標準的服務,但這些通訊協定在任兩個實作之間仍會有些微差異。While the service is standards-compliant, there can be subtle differences between any two implementations of these protocols. 若您想要透過直接傳送和處理 HTTP 要求,或使用第三方開放原始碼程式庫來撰寫程式碼,而非使用我們的其中一個開放原始碼程式庫,可以參考這裡提供的實用資訊。The information here will be useful if you choose to write your code by directly sending and handling HTTP requests or use a third party open-source library, rather than using one of our open-source libraries.

注意

Microsoft 身分識別平臺端點並非支援所有的 Azure AD 案例和功能。Not all Azure AD scenarios and features are supported by the Microsoft identity platform endpoint. 若要判斷您是否應該使用 Microsoft 身分識別平臺端點, 請參閱microsoft 身分識別平臺限制To determine if you should use the Microsoft identity platform endpoint, read about Microsoft identity platform limitations.

基本概念The basics

幾乎在所有的 OAuth 2.0 和 OpenID Connect 流程中,都有四個參與交換的合作對象:In nearly all OAuth 2.0 and OpenID Connect flows, there are four parties involved in the exchange:

顯示 OAuth 2.0 角色的圖表

  • 授權伺服器是 Microsoft 身分識別平臺端點, 負責確保使用者的身分識別、授與及撤銷資源的存取權, 以及發行權杖。The Authorization Server is the Microsoft identity platform endpoint and responsible for ensuring the user's identity, granting and revoking access to resources, and issuing tokens. 授權伺服器也稱為識別提供者:安全地處理與使用者資訊、使用者存取權,以及流程中合作對象彼此間信任關係有關的任何項目。The authorization server also known as the identity provider - it securely handles anything to do with the user's information, their access, and the trust relationships between parties in a flow.
  • 資源擁有者通常是使用者。The Resource Owner is typically the end user. 其是擁有資料的一方,而且有權允許第三方存取該資料或資源。It's the party that owns the data and has the power to allow third parties to access that data or resource.
  • OAuth 用戶端是您的應用程式,透過其應用程式識別碼加以識別。The OAuth Client is your app, identified by its application ID. OAuth 用戶端通常是與使用者互動的對象,而且會向授權伺服器要求權杖。The OAuth client is usually the party that the end user interacts with, and it requests tokens from the authorization server. 用戶端必須獲得資源擁有者授權才能存取資源。The client must be granted permission to access the resource by the resource owner.
  • 資源伺服器 是資源或資料所在位置。The Resource Server is where the resource or data resides. 它會信任授權伺服器, 以安全地驗證和授權 OAuth 用戶端, 並使用持有人存取權杖來確保能夠授與資源的存取權。It trusts the Authorization Server to securely authenticate and authorize the OAuth Client, and uses Bearer access tokens to ensure that access to a resource can be granted.

App 註冊App Registration

每個想要接受個人和公司或學校帳戶的應用程式都必須透過Azure 入口網站中的應用程式註冊體驗來註冊, 才能使用 OAuth 2.0 或 OpenID connect 將這些使用者簽入。Every app that wants to accept both personal and work or school accounts must be registered through the App registrations experience in the Azure portal before it can sign these users in using OAuth 2.0 or OpenID Connect. 應用程式註冊處理序會收集與指派一些值給您的應用程式:The app registration process will collect and assign a few values to your app:

  • 可唯一識別應用程式的「應用程式識別碼」An Application ID that uniquely identifies your app
  • 可用於將回應導向回到應用程式的重新導向 URI (選擇性)A Redirect URI (optional) that can be used to direct responses back to your app
  • 其他幾個狀況特定的值。A few other scenario-specific values.

如需詳細資訊,請瞭解如何 註冊應用程式For more details, learn how to register an app.

端點Endpoints

註冊之後, 應用程式會將要求傳送至端點, 以與 Microsoft 身分識別平臺進行通訊:Once registered, the app communicates with Microsoft identity platform by sending requests to the endpoint:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

其中 {tenant} 可以接受下列這四個不同值的其中一個:Where the {tenant} can take one of four different values:

Value 描述Description
common 允許使用者使用個人的 Microsoft 帳戶和工作/學校帳戶,從 Azure AD 登入應用程式。Allows users with both personal Microsoft accounts and work/school accounts from Azure AD to sign into the application.
organizations 僅允許使用者使用工作/學校帳戶,從 Azure AD 登入應用程式。Allows only users with work/school accounts from Azure AD to sign into the application.
consumers 僅允許使用者使用個人的 Microsoft 帳戶 (MSA) 登入應用程式。Allows only users with personal Microsoft accounts (MSA) to sign into the application.
8eaef023-2b34-4da1-9baa-8bc8c9d6a490contoso.onmicrosoft.com8eaef023-2b34-4da1-9baa-8bc8c9d6a490 or contoso.onmicrosoft.com 僅允許使用者使用工作/學校帳戶,從特定的 Azure AD 租用戶登入應用程式。Allows only users with work/school accounts from a particular Azure AD tenant to sign into the application. 可以使用 Azure AD 租用戶的易記網域名稱,或是租用戶的 GUID 識別碼。Either the friendly domain name of the Azure AD tenant or the tenant's GUID identifier can be used.

若要了解如何與這些端點互動,請在通訊協定區段選擇特定的應用程式類型,然後遵循連結以取得更多資訊。To learn how to interact with these endpoints, choose a particular app type in the Protocols section and follow the links for more info.

提示

在 Azure AD 中註冊的任何應用程式都可以使用 Microsoft 身分識別平臺端點, 即使他們未登入個人帳戶也一樣。Any app registered in Azure AD can use the Microsoft identity platform endpoint, even if they don't sign in personal accounts. 如此一來, 您就可以將現有的應用程式遷移至 Microsoft 身分識別平臺和MSAL , 而不需要重新建立您的應用程式。This way, you can migrate existing applications to Microsoft identity platform and MSAL without re-creating your application.

權杖Tokens

OAuth 2.0 和 OpenID Connect 的 Microsoft 身分識別平臺執行會大量使用持有人權杖, 包括以 Jwt 表示的持有人權杖。The Microsoft identity platform implementation of OAuth 2.0 and OpenID Connect make extensive use of bearer tokens, including bearer tokens represented as JWTs. 持有人權杖是輕巧型的安全性權杖,授權「持有者」存取受保護的資源。A bearer token is a lightweight security token that grants the “bearer” access to a protected resource. 從這個意義上說,「持有者」是可出示權杖的任何一方。In this sense, the “bearer” is any party that can present the token. 雖然某一方必須先向 Microsoft 身分識別平臺驗證, 才能接收持有人權杖, 但如果未採取必要的步驟來保護傳輸和儲存中的權杖, 則可能會被非預期的一方攔截和使用。Though a party must first authenticate with Microsoft identity platform to receive the bearer token, if the required steps are not taken to secure the token in transmission and storage, it can be intercepted and used by an unintended party. 雖然某些安全性權杖都有內建的機制,可防止未經授權的人士使用權杖,但持有者權杖沒有這項機制,而必須以安全通道來傳輸,例如傳輸層安全性 (HTTPS)。While some security tokens have a built-in mechanism for preventing unauthorized parties from using them, bearer tokens do not have this mechanism and must be transported in a secure channel such as transport layer security (HTTPS). 如果持有人權杖以未加密狀態傳輸,惡意人士就可以使用中間人攻擊來取得該權杖,並在未獲得授權的情況下用它存取受保護的資源。If a bearer token is transmitted in the clear, a malicious party can use a man-in-the-middle attack to acquire the token and use it for unauthorized access to a protected resource. 儲存或快取持有者權杖供以後使用時,也適用相同的安全性原則。The same security principles apply when storing or caching bearer tokens for later use. 務必確定您的應用程式以安全的方式傳輸和儲存持有人權杖。Always ensure that your app transmits and stores bearer tokens in a secure manner. 關於持有者權杖的其他安全性考量,請參閱 RFC 6750 第 5 節For more security considerations on bearer tokens, see RFC 6750 Section 5.

如需 Microsoft 身分識別平臺端點中所用不同權杖類型的詳細資訊, 請參閱 microsoft 身分識別平臺端點權杖參考Further details of different types of tokens used in the Microsoft identity platform endpoint is available in the Microsoft identity platform endpoint token reference.

通訊協定Protocols

若您準備好查看部分範例要求,請開始使用以下的其中一個教學課程。If you're ready to see some example requests, get started with one of the below tutorials. 每個教學課程皆對應至特定的驗證案例。Each one corresponds to a particular authentication scenario. 如果您需要協助來判斷哪一個是正確的流程, 請參閱您可以使用 Microsoft 身分識別平臺來建立的應用程式類型If you need help determining which is the right flow for you, check out the types of apps you can build with Microsoft identity platform.