Microsoft 身分識別平台的應用程式類型
Microsoft 身分識別平台支援各種新式應用程式結構的驗證，全都以產業標準通訊協定 OAuth 2.0 或 OpenID Connect 為基礎。 本文描述您可以使用 Microsoft 身分識別平台建置的應用程式類型，不論您慣用的語言或平台是哪一種。 這些資訊的設計目的是協助您先了解高階的案例，再開始使用應用程式案例中的程式碼。
基本知識
您必須在 Microsoft Entra 系統管理中心應用程式註冊中註冊每個使用 Microsoft 身分識別平台的應用程式。 應用程式註冊程序會為您的應用程式收集和指派下列值：
- 可唯一識別應用程式的應用程式 (用戶端) 識別碼
- 可用來將回應導回到應用程式的「重新導向 URI」
- 幾個其他情境特定的值，例如支援的帳戶類型
如需詳細資訊，請了解如何註冊應用程式。
註冊應用程式之後，應用程式即會向端點傳送要求以與 Microsoft 身分識別平台通訊。 我們提供開放原始碼架構，以及可處理這些要求詳細資料的程式庫。 您也可以選擇發送請求到這些API端點，來自行實作驗證邏輯：
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 小時，而且過期之後，必須使用重新整理權杖來要求另一個代碼。 除了存取權杖以外，通常會透過相同的流程和/或個別的 OpenID Connect 請求（此處未顯示）來要求一個id_token，用來代表已登入之使用者給用戶端應用程式。
若要查看實際效果，請參閱快速入門：使用 JavaScript 在單頁應用程式 (SPA) 中登入使用者，並呼叫 Microsoft Graph API。
Web 應用程式
針對使用者透過瀏覽器存取的 Web 應用程式 (.NET、PHP、Java、Ruby、Python、Node)，您可以使用 OpenID Connect 來執行使用者登入。 在 OpenID Connect 中，網頁應用程式會收到 ID 權杖。 ID 權杖是一種安全性權杖，用於確認使用者的身分，並以宣告的形式提供使用者的相關資訊。
// 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 伺服器應用程式中，登入驗證流程會採用下列概要步驟：
您可以使用從 Microsoft 身分識別平台接收的公開簽署金鑰來驗證 ID 權杖，以確保使用者的身分。 系統會設定一個工作階段 Cookie，這個 Cookie 可以在使用者隨後的頁面請求中用來識別其身份。
了解更多方法是透過建立 ASP.NET Core 網頁應用程式，以供使用者登入並呼叫 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 存取權杖來保護其資料及驗證傳入請求，而不是使用 ID 權杖和工作階段 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 的概要流程看起來像這樣：
若要了解如何使用 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 API) 的方法。 這些應用程式可以使用應用程式的身分識別 (而非使用者委派的身分識別) 搭配 OAuth 2.0 用戶端認證流程，來驗證及取得權杖。 您可以使用用戶端密碼或憑證來提供應用程式的身分識別。 如需詳細資訊，請參閱使用 Microsoft 身分識別平台的 .NET 精靈主控台應用程式。
在此流程中，應用程式會直接與 /token 端點互動來取得存取權：
若要建置精靈應用程式，請參閱用戶端認證文件，或試試 .NET 範例應用程式。