管理零信任代幣

在 零信任應用程式開發中，明確定義應用程式的意圖及其資源存取需求非常重要。 你的應用程式應該只要求它運作所需的存取權限。 本文協助你作為開發者，透過 ID 令牌、存取權杖以及 Microsoft 身份平台能接收的安全令牌，為你的應用程式內建安全性。

確保您的應用程式遵循零信任 原則中的最小權限 原則，並防止以損害你意圖的方式使用。 使用 Just-In-Time 和 Just-Enough-Access (JIT/JEA)、風險型調適型原則以及資料保護來限制使用者存取權。 將應用程式中敏感與強大的部分分開。 僅提供授權使用者進入這些區域。 限制能使用你的應用程式的使用者以及他們在應用程式中的功能權限。

在應用程式管理從 Microsoft 身份平台接收的 ID 權杖時，建立最小權限。 ID Tokens 中的資訊讓您能驗證使用者是否真實身份。 使用者或其組織可能會指定認證條件，如多重驗證（MFA）、受管理裝置及正確位置。

讓客戶輕鬆管理應用程式授權。 減少使用者建立與設定的負擔及手動流程。 自動使用者配置 讓 IT 管理員能自動化目標身份資料庫中的使用者身份建立、維護與移除。 您的客戶可以透過 應用程式配置 或 Microsoft Entra ID 中的人力資源驅動配置 ，根據使用者與群組的變更來自動化。

在你的應用程式中使用代幣聲明

在應用程式中使用 ID 標記中的聲明作為資料庫的索引鍵，以提升使用者體驗。 提供客戶端應用程式的存取權限。 ID 憑證是 OpenID Connect （OIDC）對 OAuth 2.0 的核心擴充。 你的應用程式可以同時或取代存取權杖一起接收 ID 代幣。

在安全權杖授權的標準模式中，發出的 ID 令牌允許應用程式接收關於使用者的資訊。 不要用 ID 憑證作為存取資源的授權流程。 授權伺服器會發出包含包含以下使用者資訊的聲明的 ID 憑證。

  • 受眾聲明是您的應用程式的用戶端 ID。 只接受與您的 API 客戶端 ID 相關的權杖。
  • 宣告 tid 是簽發令牌的租戶的ID。 oid聲明是一個不可變的值，用來唯一識別使用者。 當你需要將資料與使用者關聯時，使用 tid 和 oid 聲明的獨特組合作為用戶鍵。 利用這些理賠值將你的資料與 Microsoft Entra ID 中的使用者 ID 連結起來。
  • sub主張是一個不可改變的值，唯一地識別使用者。 主題聲明對於你的應用程式是獨一無二的。 如果您使用 sub 的宣告將資料與使用者關聯，就無法從您的資料連結到 Microsoft Entra ID 中的使用者。

您的應用程式可以使用範圍 openid 向 Microsoft 身份平台申請 ID 憑證。 OIDC 標準規範 openid 範圍、ID 令牌的格式與內容。 OIDC 規定了以下 範圍：

  • 利用 openid scope 登入使用者，並在 ID 標記中新增 sub 聲明。 這些範圍提供一個對應用程式與使用者獨一無二的使用者 ID，並呼叫 UserInfo 端點。
  • email範圍會在 email ID 標記中新增一個包含使用者電子郵件地址的宣告。
  • profile 範圍會將包含使用者基本資料屬性（姓名、使用者名稱）的聲明新增至 ID 標記。
  • 這個 offline_access 範圍允許應用程式在使用者不在場時存取使用者資料。

Microsoft 認證函式庫（MSAL）總是在每個令牌請求中加入 openid、電子郵件和profile範圍。 因此，MSAL 每次呼叫 AcquireTokenSilent 或 AcquireTokenInteractive 時，都會回傳一個 ID 令牌和一個存取權杖。 MSAL 總是請求 offline_access 範圍。 Microsoft 身份平台即使在請求應用程式未指定offline_access範圍時，仍會回傳offline_access範圍。

Microsoft 使用 OAuth2 標準來發行存取權杖。 OAuth2 標準說你會收到一個代幣，但並未說明代幣格式或代幣中需要包含什麼。 當你的應用程式需要存取 Microsoft Entra ID 保護的資源時，應該使用該資源定義的範圍。

例如，Microsoft Graph 定義 User.Read 了授權應用程式存取目前使用者完整使用者資料及租戶名稱的範圍。 Microsoft Graph 定義了該 API 中所有功能範圍的 權限 。

授權後，Microsoft 身份平台會回傳一個存取權杖給你的應用程式。 當你呼叫該資源時，你的應用程式會將這個權杖作為 HTTP 請求 API 授權標頭的一部分提供。

管理代幣壽命

應用程式可在驗證成功完成後，使用 Microsoft Entra ID 為使用者建立會話。 使用者會話管理決定使用者需要重複驗證的頻率。 它在讓明確驗證過的使用者擁有正確權限和適當時間的情況下，持續使用應用程式至關重要。 會話壽命必須根據 exp ID 標記中的聲明來決定。 聲明 exp 是 ID 憑證到期的時間，以及無法再使用該憑證驗證使用者的時間。

請務必尊重存取權杖回應中提供的 憑證壽命 ，或 exp ID 憑證中的聲明。 規範代幣壽命的條件可能包括企業的登入頻率。 你的應用程式無法設定令牌壽命。 你不能申請象徵性的終身合約。

一般來說，請確保代幣有效且未過期。 受眾聲明aud必須與客戶 ID 相符。 確保代幣來自可信的發行機構。 如果你有多租戶 API，可能會選擇篩選，只有特定租戶能呼叫你的 API。 務必執行代幣的有效期限。 檢查 nbf （起始時間）和 exp （到期時間）聲明，確保目前時間在這兩個聲明的數值範圍內。

不要追求特別長或過短的療程壽命。 讓ID代幣的存活時間來主導這個決定。 讓您的應用程式會話在代幣有效期之外保持活躍，違反了促使 IT 管理員設定代幣有效期限以防止未經授權存取的規則、政策與疑慮。 短暫的會話會降低使用者體驗，也不一定能提升安全性。 像 ASP.NET 這樣的熱門框架允許你根據 Microsoft Entra ID 權杖的到期時間來設定會話和 cookie 逾時。 遵循身份提供者的令牌到期時間，確保使用者的會話時間不會超過身份提供者所規定的政策。

快取與刷新標記

記得適當地緩存代幣。 MSAL 會自動快取標記，但標記有生命週期。 在代幣的整個壽命週期中使用它們，並適當地對其進行快取處理。 如果您反覆請求相同的令牌，流量限制會導致您的應用程序反應變慢。 若您的應用程式濫用代幣發放，發放新代幣的時間會延長。

MSAL 函式庫管理 OAuth2 協定的細節，包括刷新權杖的機制。 如果您沒有使用 MSAL，請確保您選擇的函式庫能有效利用 刷新令牌。

當你的客戶端取得存取權杖以存取受保護資源時，會收到一個刷新權杖。 當前的存取權杖到期後，使用更新令牌來取得新的存取/更新令牌組。 使用更新令牌來取得其他資源的額外存取令牌。 刷新權杖綁定於使用者與用戶端的組合（而非資源或租戶）。 你可以使用更新權杖，在你的應用程式擁有權限的任何資源和租戶組合中獲取存取權杖。

管理代幣錯誤與系統錯誤

您的應用程式絕不應嘗試驗證、解碼、檢查、解釋或檢查存取權杖的內容。 這些操作完全由資源 API 負責。 如果你的應用程式嘗試檢查存取權杖的內容，當 Microsoft 身份平台發出加密令牌時，應用程式很可能會當機。

極少數情況下，呼叫取用令牌會因網路、基礎設施或認證服務故障或中斷等問題而失敗。 若發生令牌取得失敗，請遵循以下最佳實務提升應用程式的認證體驗韌性：

  • 本地快取並安全加密憑證。
  • 不要在非安全通道上傳遞像代幣這類的安全產物。
  • 了解並處理身份提供者的例外與服務回應。

開發者常常會問，關於如何查看代幣內部以除錯問題，例如呼叫資源時會收到 401 錯誤。 隨著越來越多加密的令牌阻止你查看存取令牌內部，你需要尋找替代方案來查看存取令牌。 在除錯時，包含存取權杖的權杖回應會提供你需要的資訊。

在你的程式碼中，檢查錯誤類別，而不是單一錯誤案例。 例如，當系統未授予權限時，應優先處理必要的使用者互動，而不是個別錯誤。 因為你可能會錯過這些個別案例，最好檢查像是使用者互動這類分類器，而不是細究個別錯誤代碼。

你可能需要回退到 AcquireTokenInteractive，並提供 AcquireTokenSilent 呼叫所需的認證挑戰。 這樣做能確保互動請求的有效管理。

下一步

  • Last updated on