本指南可協助你辨識 Microsoft Entra ID Auth SDK(sidecar)與同處理序 Microsoft.Identity.Web 程式庫在應用程式中處理驗證時的差異。 Microsoft。Identity.Web 函式庫可直接整合至 .NET 應用程式中,以提升最大效能。 Microsoft Entra ID Auth SDK(側車)作為獨立容器運行,並透過 HTTP API 支援任何程式語言。 選擇正確的方法取決於你應用程式的架構、語言和部署環境。
架構差異
根本區別在於 身份驗證邏輯的執行位置。 Microsoft。Identity.Web 運行在您的申請流程中。 Microsoft Entra ID 驗證 SDK(sidecar)會作為獨立服務,與您的應用程式並行運作。 這種架構選擇會影響開發工作流程和操作複雜性等因素。
| 層面 | Microsoft.Identity.Web(In-Process) | Microsoft Entra ID 驗證 SDK(邊車)(處理序外) |
|---|---|---|
| 製程邊界 | 與您的應用程式共用相同的處理程序、記憶體和生命週期,從而實現直接方法呼叫和共用配置 | 保持完全隔離,僅透過 HTTP API 進行通信並獨立管理自己的資源 |
| 語言耦合 | 它將你的認證策略緊密結合到 .NET,這需要你對 C# 有經驗,並且在所有需要認證的地方都必須使用 .NET 執行環境。 | 將認證與應用程式的技術堆疊解耦,呈現一個語言無關的 HTTP 介面,能同時適用於 Python、Node.js、Go 或任何支援 HTTP 的語言 |
| 部署模型 | 以內嵌在應用程式二進位檔中的 NuGet 套件部署,生成單一結構的部署單位 | 部署為個別的容器映像,啟用驗證邏輯的獨立版本控制、擴展和更新,而不會影響您的應用程式程式碼 |
Microsoft。Identity.Web(進行中)
這段程式碼片段展示了如何將 Microsoft.Identity.Web 直接整合到 ASP.NET Core 應用程式中:
// Startup configuration
services.AddMicrosoftIdentityWebApiAuthentication(Configuration)
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("Graph", Configuration.GetSection("DownstreamApis:Graph"))
.AddInMemoryTokenCaches();
// Usage in controller
public class MyController : ControllerBase
{
private readonly IDownstreamApi _downstreamApi;
public MyController(IDownstreamApi downstreamApi)
{
_downstreamApi = downstreamApi;
}
public async Task<ActionResult> GetUserData()
{
var user = await _downstreamApi.GetForUserAsync<User>("Graph",
options => options.RelativePath = "me");
return Ok(user);
}
}
Microsoft Entra ID 身分驗證 SDK(Sidecar)(處理序外)
這段程式碼片段示範如何在 Node.js 應用程式中透過 HTTP 呼叫 Microsoft Entra ID Auth SDK(Sidecar)。 對 SDK 的端點 /DownstreamApi 的呼叫將會處理權杖的取得以及下游的 API 呼叫,其中包括在標頭 Authorization 中傳遞 OBO 流程的傳入權杖。
// Configuration
const SidecarUrl = process.env.SIDECAR_URL || "http://localhost:5000";
// Usage in application
async function getUserData(incomingToken: string) {
const response = await fetch(
`${SidecarUrl}/DownstreamApi/Graph?optionsOverride.RelativePath=me`,
{
headers: {
'Authorization': `Bearer ${incomingToken}`
}
}
);
const result = await response.json();
return JSON.parse(result.content);
}
特徵比較
| 特徵 / 功能 | Microsoft。Identity.Web | Microsoft Entra ID Auth SDK (sidecar) |
|---|---|---|
| 語言支持 | 僅支援 C# / .NET | 任何語言 (HTTP) |
| Deployment | 同一進程中的程式庫 | 獨立容器 |
| 代幣獲取 | 直接使用 MSAL.NET | 透過 HTTP API |
| 令牌快取 | 記憶體內,分散式 | 記憶體內,分散式 |
| OBO流程 | 原生支援 | 透過 HTTP 端點 |
| 客戶端認證 | 原生支援 | 透過 HTTP 端點 |
| 受控識別 | 直接支持 | 直接支持 |
| 客服專員身分 | 經由擴充套件 | 查詢參數 |
| 令牌驗證 | 中介軟體 | /驗證端點 |
| 下游 API | IDownstreamAPI | /DownstreamApi 端點 |
| Microsoft Graph | Graph SDK 整合 | 透過 "DownstreamApi" |
| 效能 | 進行中(最快) | HTTP 負擔 |
| Configuration |
appsettings.json 和代碼 |
appsettings.json 以及環境變數 |
| 偵錯 | 標準 .NET 除錯 | 容器除錯 |
| 即時重載 | .NET 熱重新載入(即時重新載入功能) | 容器重新啟動 |
| 套件更新 | NuGet 套件 | 容器映像 |
| 授權 | 麻省理工學院 | 麻省理工學院 |
何時使用每種方法
在 Microsoft.Identity.Web 與 Microsoft Entra ID Auth SDK(sidecar)之間做選擇,取決於您應用程式的需求、架構和部署策略。 根據你的需求,其中一種方式可能比另一種更合適。 以下指引能幫助你做出明智的決定。
| Scenario | Microsoft.Identity.Web(In-Process) | Microsoft Entra ID 驗證 SDK(側車)(處理序外) |
|---|---|---|
| 應用堆疊 | .NET 專用應用程式 • ASP.NET Core 網頁 API • ASP.NET 核心 Web 應用程序 • .NET 工作者服務 • Blazor 應用程式 • 守護程式應用程式 |
多語言微服務 • Node.js、Python、Go、Java服務 • 多語言架構 • 非 .NET 服務 • 遺留系統集成 |
| 性能要求 | 效能至關重要 • 高吞吐量場景 • 延遲敏感操作 • 每一毫秒都很重要 |
可以容忍 HTTP 額外負荷 • 可接受 ~1-5 毫秒的額外延遲 • 吞吐量不受到身份驗證過程的瓶頸影響 |
| 整合需求 | 需要深度集成 • 自訂 MSAL.NET 設定 • 直接訪問 MSAL 功能 • 高級令牌緩存策略 |
標準化整合 • 足夠的 HTTP API • 跨服務一致的身份驗證模式 |
| 開發經驗 | 快速發展 • 快速原型製作 為開發進行熱重載 • 標準 .NET 除錯 |
容器型開發 • 容器重新啟動以進行更改 • 需要容器調試 |
| 團隊與架構 | 單一語言堆疊 • 團隊專精於 C#/.NET • 無多語言要求 |
技術多樣性 • 框架和語言的混合 • 多語言團隊結構 |
| 部署模型 | 單體式部署 • 單一應用程式部署 • 傳統託管模式 |
容器化部署 • Kubernetes 環境 • Docker Compose 設置 • 服務網格架構 |
| Operations | 耦合驗證更新 • 身份驗證更改需要重建應用程序 • 與應用程序共享生命週期 |
營運優勢 • 獨立擴展身份驗證邏輯 • 將身份驗證更新與應用程序代碼分開 • 集中監控身份驗證 |
移轉指引
從 Microsoft.Identity.Web 遷移至 Microsoft Entra ID Auth SDK (sidecar)
在某些情況下,你可能會想將使用 Microsoft.Identity.Web 的現有 .NET 應用程式遷移為使用 Microsoft Entra ID Auth SDK(Sidecar)進行驗證。 遷移的原因可能包括採用多語言架構、跨服務標準化認證,或轉向容器化部署模式。
在做出這項變更前,需要仔細考慮與規劃。 本節提供高階移轉路徑,其中包含程式碼範例,以協助您轉換應用程式。
謹慎
Microsoft 不建議從 Microsoft.Identity.Web 移轉至 Microsoft Entra ID Auth SDK(sidecar)。 如果你選擇做這個改變,以下範例展示了其他語言和框架中類似的概念。
步驟 1:部署 SDK 容器
首先,將 SDK 容器加入你的 pod:
# Before: Single ASP.NET Core container
containers:
- name: app
image: myregistry/myapp:latest
# After: App + Microsoft Entra ID Auth SDK (sidecar)
containers:
- name: app
image: myregistry/myapp:latest
env:
- name: SIDECAR_URL
value: "http://localhost:5000"
- name: sidecar
image: mcr.microsoft.com/entra-sdk/auth-sidecar:1.0.0
env:
- name: AzureAd__TenantId
value: "your-tenant-id"
- name: AzureAd__ClientId
value: "your-client-id"
步驟 2:移轉組態
接著,將你的設定從appsettings.json轉移到環境變數:
之前(appsettings.json)
{
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"TenantId": "your-tenant-id",
"ClientId": "your-client-id"
},
"DownstreamApis": {
"Graph": {
"BaseUrl": "https://graph.microsoft.com/v1.0",
"Scopes": "User.Read Mail.Read",
"RelativePath": "/me"
}
}
}
之後(Kubernetes ConfigMap / 環境變數)
apiVersion: v1
kind: ConfigMap
metadata:
name: sidecar-config
data:
AzureAd__Instance: "https://login.microsoftonline.com/"
AzureAd__TenantId: "your-tenant-id"
AzureAd__ClientId: "your-client-id"
DownstreamApis__Graph__BaseUrl: "https://graph.microsoft.com/v1.0"
DownstreamApis__Graph__Scopes: "User.Read Mail.Read"
DownstreamApis__Graph__RelativePath: "/me"
步驟3:更新申請碼
找出所有對 Microsoft.Identity.Web 的處理序內呼叫,並將其替換為對 Microsoft Entra ID Auth SDK(sidecar)端點發出的 HTTP 呼叫:
之前 (具有 IDownstreamApi 的 C#):
public class UserController : ControllerBase
{
private readonly IDownstreamApi _downstreamApi;
public UserController(IDownstreamApi downstreamApi)
{
_downstreamApi = downstreamApi;
}
[HttpGet]
public async Task<ActionResult<User>> GetMe()
{
var user = await _downstreamApi.GetForUserAsync<User>(
"Graph",
options => options.RelativePath = "me"
);
return Ok(user);
}
}
之後(任何具有 HTTP 用戶端的語言):
在以下程式碼片段中,你會看到呼叫 Microsoft Entra ID Auth SDK(sidecar)並透過 /DownstreamApi 端點取得使用者資料。 範例以 C# 和 TypeScript 提供。
public class UserController : ControllerBase
{
private readonly HttpClient _httpClient;
private readonly string _SidecarUrl;
public UserController(IHttpClientFactory httpClientFactory, IConfiguration config)
{
_httpClient = httpClientFactory.CreateClient();
_SidecarUrl = config["SIDECAR_URL"];
}
[HttpGet]
public async Task<ActionResult<User>> GetMe()
{
var inboundAuthorizationHeader = Request.Headers["Authorization"].ToString();
// this validates the inbound authorization header and calls the downstream API.
// If you don't call a downstream API, Do validate the inbound authorization header
// (calling the /Validate endpoint)
var request = new HttpRequestMessage(
HttpMethod.Get,
$"{_SidecarUrl}/DownstreamApi/Graph?optionsOverride.RelativePath=me"
);
request.Headers.Add("Authorization", inboundAuthorizationHeader);
var response = await _httpClient.SendAsync(request);
var result = await response.Content.ReadFromJsonAsync<SidecarResponse>();
var user = JsonSerializer.Deserialize<User>(result.Content);
return Ok(user);
}
}
TypeScript
你可以在 TypeScript 中實作相同的邏輯如下:
export async function getMe(incomingToken: string): Promise<User> {
const SidecarUrl = process.env.SIDECAR_URL!;
const response = await fetch(
`${SidecarUrl}/DownstreamApi/Graph?optionsOverride.RelativePath=me`,
{
headers: {
'Authorization': incomingToken
}
}
);
const result = await response.json();
return JSON.parse(result.content) as User;
}
步驟四:移除 Microsoft。Identity.Web 相依關係
完成前述步驟後,從你的專案中移除 Microsoft.Identity.Web 的 NuGet 套件來整理你的應用程式。
<!-- Remove these from .csproj -->
<PackageReference Include="Microsoft.Identity.Web" Version="..." />
<PackageReference Include="Microsoft.Identity.Web.MicrosoftGraph" Version="..." />
<PackageReference Include="Microsoft.Identity.Web.DownstreamApi" Version="..." />
如果你還想在應用程式中驗證憑證,就不需要移除原本的認證設定。 相反地,你可以將驗證完全交由 Microsoft Entra ID Auth SDK(sidecar)處理。
// Remove from Program.cs or Startup.cs
services.AddMicrosoftIdentityWebApiAuthentication(Configuration)
.EnableTokenAcquisitionToCallDownstreamApi()
.AddDownstreamApi("Graph", Configuration.GetSection("DownstreamApis:Graph"))
.AddInMemoryTokenCaches();
步驟五:測試與驗證
- 單元測試:更新測試以模擬 HTTP 呼叫給 SDK。
- 整合測試:測試 SDK 在預備環境中的溝通。
- 效能測試:衡量 HTTP 開銷影響。
- 安全測試:驗證憑證處理與網路政策。
效能考量
SDK 開銷
Microsoft Entra ID 驗證 SDK(sidecar)會產生 HTTP 通訊開銷:
| 性能因素 | Impact | 緩解策略 |
|---|---|---|
| Latency | 每次本地主機通訊請求約需 1 至 5 毫秒 | 使用 HTTP/2 來減少連線負擔。 |
| Throughput | 受 HTTP 連線集區限制 | 實作連線池來重用 HTTP 連線。 |
| 記憶體 | 容器記憶體的額外開銷 | 確保 SDK 資源分配充足。 |
| 請求效率 | 複雜操作的多次往返 | 批次請求在可能時合併多個操作。 |
| 代幣表現 | 重複的代幣獲取開銷 | 善用 SDK 的代幣快取以達到最佳效能。 |
過程中表現
使用 Microsoft。Identity.Web 的開銷很低,因為它和你的應用程式在同一個流程中運作。 它提供原生方法呼叫,具備微秒延遲與共享程序記憶體,且不受 HTTP 限制。 當效能至關重要時,進行中整合是最佳選擇。 然而,Microsoft Entra ID Auth SDK(側車)的彈性與其與程式語言無關的設計,在許多情況下可能勝過效能上的權衡。
下表顯示同處理序使用與 Microsoft Entra ID Auth SDK(Sidecar,處理序外)使用的部分效能和成本比較:
成本考量
| 成本因素 | Microsoft.Identity.Web(In-Process) | Microsoft Entra ID 驗證 SDK(sidecar)(處理序外) |
|---|---|---|
| 計算 | 在應用程式運行中,盡量減少額外的 CPU 和記憶體使用 | 每個 Pod 提供額外的容器資源。 |
| Network | 沒有額外的額外負擔 | 本地主機的通訊極少。 |
| 儲存空間 | NuGet 套件大小(~10 MB) | 容器影像儲存。 |
| 管理 | 沒有額外的額外負擔 | 容器調度的開銷。 |
成本範例
對於 10 個副本,配備 128 MiB/100m SDK 配置:
| Resource | 處理中 | Microsoft Entra ID Auth SDK (sidecar) |
|---|---|---|
| 記憶體 | 額外 ~0 MB | 10 × 128 MiB = 1.28 GB |
| 中央處理器 | 將近0% 增加 | 10 × 100m = 1 芯 |
| 儲存空間 | 每次部署約 10 MB | 每個節點的容器映像大小 |
支援與維護
| 層面 | Microsoft。Identity.Web | Microsoft Entra ID Auth SDK (sidecar) |
|---|---|---|
| Updates | NuGet 套件更新 | 容器映像更新 |
| 重大變更 | 透過套件版本設定 | 透過容器標籤 |
| 錯誤修正 | 編譯階段整合 | 執行階段容器更新 |
| 安全性修補程式 | 重建應用程式 | 重新部署容器 |
| 文件 | 詳盡的 .NET 文件 | 此文件 |
| Community | 大型 .NET 社群 | 不斷發展的社區 |
混合式方法
你可以在同一架構中結合這兩種方法。 對於要求最高效能的 .NET 服務,請使用 Microsoft.Identity.Web;對於非 .NET 服務,或在需要與程式語言無關的驗證模式時,請使用 Microsoft Entra ID Auth SDK(sidecar)。 這種混合策略幫助您在關鍵時刻優化效能,同時維持整個服務生態系統的一致性與彈性。
以下是一個範例架構:
graph TB
subgraph cluster["Kubernetes Cluster"]
subgraph netpod["<b>.NET API Pod</b>"]
netapi["<b>.NET API</b><br/>(Microsoft.Identity.Web)"]
style netapi fill:#0078d4,stroke:#005a9e,stroke-width:2px,color:#fff
end
subgraph nodepod["<b>Node.js API Pod</b>"]
nodeapi["<b>Node.js API</b>"]
sidecar["<b>Microsoft Entra ID Auth SDK (sidecar)</b>"]
style nodeapi fill:#68a063,stroke:#4a7c45,stroke-width:2px,color:#fff
style sidecar fill:#f2711c,stroke:#d85e10,stroke-width:2px,color:#fff
end
end
style cluster fill:#f0f0f0,stroke:#333,stroke-width:3px
style netpod fill:#e8f4f8,stroke:#0078d4,stroke-width:2px
style nodepod fill:#e8f4e8,stroke:#68a063,stroke-width:2px