藉由驗證宣告來保護應用程式和 API

與令牌互動是建置應用程式以授權使用者的核心部分。 根據最低特殊許可權存取的 零信任 原則，應用程式在執行授權時驗證存取令牌中存在之特定宣告的值至關重要。

宣告型授權可讓應用程式確保令牌包含令牌中存在租用戶、主體和動作專案等專案的正確值。 話說來，鑒於各種方法來利用和案例來追蹤，宣告型授權似乎很複雜。 本文旨在簡化宣告型授權程式，以確保應用程式遵守最安全的作法。

若要確定授權邏輯安全，您必須在宣告中驗證下列資訊：

• 為令牌指定適當的物件。
• 令牌的租用戶標識碼符合儲存數據之租用戶的標識碼。
• 令牌的主體是適當的。
• 動作專案 （用戶端應用程式） 已獲得授權。

注意

存取令牌只會在用戶端取得的 Web API 中驗證。 用戶端不應該驗證存取令牌。

如需本文中所提及宣告的詳細資訊，請參閱 Microsoft 身分識別平台 存取令牌。

驗證物件

宣告 aud 會識別令牌的預期物件。 驗證宣告之前，您必須一律確認存取令牌中包含的宣告值 aud 符合 Web API。 此值取決於用戶端要求令牌的方式。 存取權杖中的物件取決於端點：

• 針對 v2.0 令牌，對像是 Web API 的用戶端識別碼。 這是 GUID。
• 針對 v1.0 令牌，對像是 Web API 中宣告的其中一個 appID URI，可驗證令牌。 例如， api://{ApplicationID}或以功能變數名稱開頭的唯一名稱（如果功能變數名稱與租使用者相關聯）。

如需應用程式之 appID URI 的詳細資訊，請參閱 應用程式識別碼 URI。

驗證租使用者

一律檢查 tid 令牌中的 符合用來儲存應用程式數據的租用戶標識碼。 當應用程式的資訊儲存在租用戶的內容中時，應該只會在稍後在同一個租使用者中再次存取。 絕不允許從另一個租使用者存取某個租用戶中的數據。

租用戶的驗證只是第一個步驟，仍需要檢查本文所述的主旨和動作專案。 如果您打算授權租使用者中的所有使用者，強烈建議您明確將這些使用者新增至群組，並根據群組授權。 例如，藉由只檢查租使用者標識碼和宣告是否存在 oid ，除了使用者之外，您的 API 也會不小心授權該租使用者中的所有服務主體。

驗證主旨

判斷令牌主體，例如使用者（或僅限應用程式令牌的應用程式本身）是否已獲得授權。

您可以檢查特定 sub 或 oid 宣告。

或者，

您可以檢查主體是否屬於具有roles、 groupswids 宣告的適當角色或群組。 例如，使用不可變的宣告值 tid ，並 oid 作為應用程式數據的合併索引鍵，並判斷是否應授與使用者存取權。

roles或 groupswids 宣告也可以用來判斷主體是否具有執行作業的授權。 例如，系統管理員可能有權寫入 API，但不能是一般使用者，或者使用者可能位於允許執行某些動作的群組中。 宣告 wid 代表從 Microsoft Entra 內建角色中存在的角色指派給使用者的全租使用者角色。 如需詳細資訊，請參閱 Microsoft Entra 內建角色。

警告

請勿使用 之類的 email宣告， preferred_username 或 unique_name 來儲存或判斷存取令牌中的使用者是否應該具有數據的存取權。 這些宣告不是唯一的，而且可由租用戶系統管理員或有時使用者控制，這使得它們不適合授權決策。 它們僅供顯示之用。 也請勿將 upn 宣告用於授權。 雖然 UPN 是唯一的，但它通常會在用戶主體的存留期內變更，這讓授權不可靠。

驗證動作專案

代表使用者運作的用戶端應用程式（稱為 動作專案），也必須獲得授權。 scp使用宣告 （scope） 來驗證應用程式是否具有執行作業的許可權。 中scp的許可權應受限於用戶實際需要的內容，並遵循最低許可權的原則。

不過，令牌中沒有出現的情況 scp 。 您應該檢查下列案例中是否有 scp 宣告：

• 精靈應用程式/僅限應用程式許可權
• 識別碼權杖

如需範圍和許可權的詳細資訊，請參閱 Microsoft 身分識別平台 中的範圍和許可權。

注意

應用程式可以處理僅限應用程式令牌（沒有使用者的應用程式要求，例如精靈應用程式），並想要跨多個租用戶授權特定應用程式，而不是個別的服務主體標識符。 在此情況下， appid 宣告（適用於 v1.0 令牌）或 azp 宣告（適用於 v2.0 令牌）可用於主體授權。 不過，使用這些宣告時，應用程式必須藉由驗證 idtyp 選擇性宣告，確保直接為應用程式發出令牌。 只有類型的 app 令牌可以透過這種方式獲得授權，因為委派的使用者令牌可由應用程式以外的實體取得。

下一步

• 深入了解安全性令牌中的 令牌和宣告