驗證宣告以保護應用程式和 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 宣告。
或者，
您可以檢查主體是否屬於具有、 、 scpgroupswids 宣告的適當角色或群組。roles 例如，使用不可變的宣告值 tid 和 oid 作為應用程式資料的合併索引鍵，並判斷是否應授與使用者存取權。
roles或 groups wids 宣告也可以用來判斷主體是否具有執行作業的授權，不過這些宣告並非主體可授與許可權之所有方式的完整清單。 例如，系統管理員可能有權寫入 API，但不是一般使用者，或者使用者可能位於允許執行某些動作的群組中。 wid 宣告代表從 Microsoft Entra 內建角色中存在的角色指派給使用者的租用戶範圍角色。 如需詳細資訊，請參閱 Microsoft Entra 內建角色。
警告
請勿使用 email、preferred_username 或 unique_name 之類的宣告來儲存或判斷存取權杖中的使用者是否應該具有資料的存取權。 這些宣告不是唯一的，且可由租用戶系統管理員或在某些情況下由使用者控制，這使得它們不適合用於授權決策。 它們僅供顯示之用。 此外，請勿將 upn 宣告用於授權。 雖然 UPN 是唯一的，但它通常會在使用者主體的存留期內變更，這讓授權並不可靠。
驗證動作項目
代表使用者運作的用戶端應用程式 (稱為動作項目)，也必須獲得授權。 使用 scp 宣告 (範圍) 來驗證應用程式是否具有執行作業的權限。 scp 中的權限應受限於使用者實際需要的內容，並遵循最低權限的原則。
不過，也有權杖中並未出現 scp 的情況。 您應該檢查下列案例中是否缺少 scp 宣告：
- 精靈應用程式/僅限應用程式權限
- 識別碼權杖
如需範圍和權限的詳細資訊，請參閱 Microsoft 身分識別平台中的範圍和權限。
注意
應用程式可以處理僅限應用程式權杖 (沒有使用者的應用程式要求，例如精靈應用程式)，且想要跨多個租用戶授權特定應用程式，而不是個別的服務主體識別碼。 在此情況下，appid 宣告 (適用於 v1.0 權杖) 或 azp 宣告 (適用於 v2.0 權杖) 可用於主體授權。 不過，使用這些宣告時，應用程式必須藉由驗證 idtyp 選擇性宣告，確保直接為應用程式發出權杖。 只有類型 app 的權杖可以透過這種方式獲得授權，因為委派的使用者權杖可由應用程式以外的實體取得。
下一步
- 深入了解安全性權杖中的權杖和宣告