Microsoft 身分識別平台的應用程式類型

發行項
11/13/2024

Microsoft 身分識別平台支援各種新式應用程式結構的驗證，全都以產業標準通訊協定 OAuth 2.0 或 OpenID Connect 為基礎。本文描述您可以使用 Microsoft 身分識別平台建置的應用程式類型，不論您慣用的語言或平台是哪一種。這些資訊的設計目的是協助您在開始使用應用程式案例中的程式碼之前，先了解概要的案例。

基本知識

您必須在 Microsoft Entra 系統管理中心應用程式註冊中註冊每個使用 Microsoft 身分識別平台的應用程式。應用程式註冊程序會為您的應用程式收集和指派下列值：

可唯一識別應用程式的應用程式 (用戶端) 識別碼
可用來將回應導回到應用程式的「重新導向 URI」
幾個其他案例特定的值，例如支援的帳戶類型

如需詳細資訊，請了解如何註冊應用程式。

註冊應用程式之後，應用程式即會向端點傳送要求以與 Microsoft 身分識別平台通訊。我們提供開放原始碼架構，以及可處理這些要求詳細資料的程式庫。您也可以選擇建立對這些端點的要求，來自行實作驗證邏輯：

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Microsoft 身分識別平台所支援的應用程式類型如下：

單頁應用程式 (SPA)
Web 應用程式
Web API
行動和原生應用程式
服務、精靈、指令碼

單一頁面應用程式

許多新式應用程式都有主要以 JavaScript 撰寫的單頁應用程式 (SPA) 前端，而且通常具有 Angular、React 或 Vue 這類架構。 Microsoft 身分識別平台支援這些應用程式，方法是使用 OpenID Connect 通訊協定進行驗證，以及 OAuth 2.0 所定義的兩種授權授與類型之一。開發 SPA 時，使用授權碼流程搭配程式代碼交換證明金鑰（PKCE）。此流程相比不再建議的隱含流程更加安全。如需詳細資訊，請參閱偏好驗證碼流程。

流程圖示範 OAuth 2.0 授權碼授與流程 (省略有關 PKCE 的詳細資料)，其中應用程式會從 Microsoft 身分識別平台 authorize 端點收到代碼，使用跨網站 Web 要求將其兌換為存取權杖和重新整理權杖。針對 SPA，存取權杖的有效期限為 1 小時，而且過期之後，必須使用重新整理權杖來要求另一個代碼。除了存取權杖以外，通常也會要求代表使用者已登入用戶端應用程式的 id_token，透過相同流程和/或個別 OpenID Connect 要求 (這裡未顯示)。

圖：顯示單頁應用程式與安全性權杖服務端點之間的 OAuth 2.0 授權碼流程。

若要查看實際效果，請參閱快速入門：使用 JavaScript 在單頁應用程式 (SPA) 中登入使用者，並呼叫 Microsoft Graph API。

Web 應用程式

針對使用者透過瀏覽器存取的 Web 應用程式 (.NET、PHP、Java、Ruby、Python、Node)，您可以使用 OpenID Connect 來執行使用者登入。在 OpenID Connect 中，Web 應用程式會收到識別碼權杖。識別碼權杖是一個安全性權杖，可驗證使用者的身分識別並以宣告形式提供使用者的相關資訊：

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

如需 Microsoft 身分識別平台中所用不同權杖類型的詳細說明，請參閱存取權杖參考和 id_token 參考。

在 Web 伺服器應用程式中，登入驗證流程會採用下列概要步驟：

顯示 Web 應用程式驗證流程

您可以使用接收自 Microsoft 身分識別平台的公開簽署金鑰來驗證識別碼權杖，來確保使用者的身分識別。系統會設定工作階段 Cookie，這可在後續的頁面要求上用來識別使用者。

建置 ASP.NET Core Web 應用程式以登入使用者並呼叫 Microsoft Graph API 以深入瞭解

除了簡易登入之外，Web 伺服器應用程式可能也需要存取其他 Web 服務，例如具象狀態傳輸 (REST) API。在此情況下，Web 伺服器應用程式可以使用 OAuth 2.0 授權碼流程，參與結合了 OpenID Connect 與 OAuth 2.0 的流程。如需此案例的詳細資訊，請參閱我們的程式代碼範例。

Web API

您可以使用 Microsoft 身分識別平台來保護 Web 服務，例如應用程式的 RESTful Web API。 Web API 能夠在多個平台以及使用多種語言實作。也可以使用 Azure Functions 中的 HTTP 觸發程序來實作。 Web API 使用 OAuth 2.0 存取權杖來保護其資料及驗證連入要求，而不是使用識別碼權杖和工作階段 Cookie。

Web API 的呼叫端會在 HTTP 要求的授權標題中附加存取權杖，就像這樣：

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

Web API 會使用這個存取權杖來驗證 API 呼叫端的身分識別，並從存取權杖中所編碼的宣告擷取呼叫端的相關資訊。如需 Microsoft 身分識別平台中所使用不同權杖類型的進一步詳細資料，請參閱存取權杖參考和識別碼權杖參考。

Web API 可透過公開權限的方式 (亦稱為範圍)，讓使用者能夠選擇加入或退出特定的功能或資料。為了讓發出呼叫的應用程式取得範圍的權限，使用者必須在流程中對範圍表示同意。 Microsoft 身分識別平台會向使用者要求權限，然後將這些權限記錄在 Web API 接收的所有存取權杖中。 Web API 會驗證它在每次呼叫所收到的存取權杖，並執行授權檢查。

Web API 可以從所有類型的應用程式接收存取權杖，包括 Web 伺服器應用程式、傳統型應用程式和行動應用程式、單頁應用程式、伺服器端精靈，甚至是其他的 Web API。 Web API 的概要流程看起來像這樣：

顯示 Web API 驗證流程

若要了解如何使用 OAuth2 存取權杖來保護 Web API，請查看受保護的 Web API 教學課程中的 Web API 程式碼範例。

在許多情況下，Web API 也需要對受 Microsoft 身分識別平台保護的其他下游 Web API 發出傳出要求。若要這樣做，Web API 可以利用「代理者 (OBO)」流程，其允許 Web API 將傳入存取權杖交換為要在傳出要求中使用的另一個存取權杖。如需詳細資訊，請參閱 Microsoft 身分識別平台和 OAuth 2.0 代理者流程。

行動和原生應用程式

裝置安裝的應用程式 (例如行動應用程式和傳統型應用程式) 通常需要存取儲存資料及代表使用者執行功能的後端服務或 Web API。這些應用程式可以使用 OAuth 2.0 授權碼流程，將登入和授權新增至後端服務。

在此流程中，應用程式會在使用者登入時，從 Microsoft 身分識別平台接收授權碼。授權碼代表應用程式具備權限，可代表登入的使用者呼叫後端服務。應用程式可以在背景中以授權碼交換 OAuth 2.0 存取權杖和重新整理權杖。應用程式可以使用存取權杖在 HTTP 要求中向 Web API 進行驗證，以及在舊存取權杖到期時，使用重新整理權杖來取得新的存取權杖。

顯示原生應用程式驗證流程

注意

如果應用程式使用預設系統 Web 檢視，則請在 Microsoft Entra 驗證和授權錯誤碼中查看「確認我的登入」功能和錯誤碼 AADSTS50199 的相關資訊。

伺服器、精靈和腳本

應用程式如果含有長時間執行的程序，或其運作方式不需要與使用者互動，就也需要一個存取受保護資源 (例如 Web API) 的方法。這些應用程式可以使用應用程式的身分識別 (而非使用者委派的身分識別) 搭配 OAuth 2.0 用戶端認證流程，來驗證及取得權杖。您可以使用用戶端密碼或憑證來提供應用程式的身分識別。如需詳細資訊，請參閱使用 Microsoft 身分識別平台的 .NET 精靈主控台應用程式。

在此流程中，應用程式會直接與 /token 端點互動來取得存取權：

顯示精靈應用程式驗證流程

若要建置精靈應用程式，請參閱用戶端認證文件，或試試 .NET 範例應用程式。

另請參閱

瞭解 OAuth 2.0 和 OpenID Connect
註冊應用程式

共用方式為