本文內容
權杖格式
權杖所有權
權杖存留期
驗證權杖
相關內容
存取權杖是一種安全性權杖類型,專為授權而設計,可代表已驗證的使用者授與特定資源的存取權。 存取權杖中的資訊會決定使用者是否有權存取特定資源,與可打開建築物中特定門的鑰匙類似。 組成權杖的這些個別資訊片段稱為宣告。 因此,其為敏感性認證,如果未正確處理,則會造成安全性風險。 存取權杖與作為驗證證明的識別碼權杖 不同。
存取權杖可讓用戶端安全地呼叫受保護的 Web API。 雖然用戶端應用程式可以接收和使用存取權杖,但應該將其視為不透明字串。 用戶端應用程式不應該嘗試驗證存取權杖。 資源伺服器應該先驗證存取權杖,再將其接受為授權證明。 權杖的內容僅適用於 API,這表示必須將存取權杖視為不透明字串。 若只要 用於驗證及偵錯,開發人員可以使用 jwt.ms 等網站來解碼 JWT。 Microsoft API 所收到的權杖不一定是可解碼的 JWT。
用戶端應該使用隨著存取權杖傳回的權杖回應資料,以取得其內部內容的詳細資料。 用戶端要求存取權杖時,Microsoft 身分識別平台也會傳回一些存取權杖相關中繼資料,以供應用程式取用。 此資訊包括存取權杖的到期時間以及其有效範圍。 此資料可讓應用程式執行存取權杖的智慧型快取,而不需要剖析存取權杖本身。 本文說明存取權杖的基本資訊,包括格式、擁有權、存留期,以及 API 如何驗證和使用存取權杖內的宣告。
注意
本頁面中的所有文件 (除非註明) 僅適用於針對已註冊 API 所核發的權杖。 其並不適用於 Microsoft 擁有的 API 所發出的權杖,也不能使用這些權杖來驗證 Microsoft 身分識別平台如何針對已註冊 API 核發權杖。
Microsoft 身分識別平台中有兩種可用的存取權杖版本:v1.0 和2.0 版。 這些版本會決定權杖中的宣告,並確定 Web API 可以控制權杖的內容。
Web API 會在註冊期間選取下列其中一個版本作為預設值:
v1.0 適用於僅限 Microsoft Entra 應用程式。 下列範例顯示 v1.0 權杖 (金鑰已變更,並移除個人資訊,這可防止權杖驗證):
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiJlZjFkYTlkNC1mZjc3LTRjM2UtYTAwNS04NDBjM2Y4MzA3NDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTUyMjIyOS8iLCJpYXQiOjE1MzcyMzMxMDYsIm5iZiI6MTUzNzIzMzEwNiwiZXhwIjoxNTM3MjM3MDA2LCJhY3IiOiIxIiwiYWlvIjoiQVhRQWkvOElBQUFBRm0rRS9RVEcrZ0ZuVnhMaldkdzhLKzYxQUdyU091TU1GNmViYU1qN1hPM0libUQzZkdtck95RCtOdlp5R24yVmFUL2tES1h3NE1JaHJnR1ZxNkJuOHdMWG9UMUxrSVorRnpRVmtKUFBMUU9WNEtjWHFTbENWUERTL0RpQ0RnRTIyMlRJbU12V05hRU1hVU9Uc0lHdlRRPT0iLCJhbXIiOlsid2lhIl0sImFwcGlkIjoiNzVkYmU3N2YtMTBhMy00ZTU5LTg1ZmQtOGMxMjc1NDRmMTdjIiwiYXBwaWRhY3IiOiIwIiwiZW1haWwiOiJBYmVMaUBtaWNyb3NvZnQuY29tIiwiZmFtaWx5X25hbWUiOiJMaW5jb2xuIiwiZ2l2ZW5fbmFtZSI6IkFiZSAoTVNGVCkiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMjIyNDcvIiwiaXBhZGRyIjoiMjIyLjIyMi4yMjIuMjIiLCJuYW1lIjoiYWJlbGkiLCJvaWQiOiIwMjIyM2I2Yi1hYTFkLTQyZDQtOWVjMC0xYjJiYjkxOTQ0MzgiLCJyaCI6IkkiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJsM19yb0lTUVUyMjJiVUxTOXlpMmswWHBxcE9pTXo1SDNaQUNvMUdlWEEiLCJ0aWQiOiJmYTE1ZDY5Mi1lOWM3LTQ0NjAtYTc0My0yOWYyOTU2ZmQ0MjkiLCJ1bmlxdWVfbmFtZSI6ImFiZWxpQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJGVnNHeFlYSTMwLVR1aWt1dVVvRkFBIiwidmVyIjoiMS4wIn0.D3H6pMUtQnoJAGq6AHd
v2.0 適用於支援取用者帳戶的應用程式。 下列範例顯示 v2.0 權杖 (金鑰已變更,並移除個人資訊,這可防止權杖驗證):
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9.eyJhdWQiOiI2ZTc0MTcyYi1iZTU2LTQ4NDMtOWZmNC1lNjZhMzliYjEyZTMiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3L3YyLjAiLCJpYXQiOjE1MzcyMzEwNDgsIm5iZiI6MTUzNzIzMTA0OCwiZXhwIjoxNTM3MjM0OTQ4LCJhaW8iOiJBWFFBaS84SUFBQUF0QWFaTG8zQ2hNaWY2S09udHRSQjdlQnE0L0RjY1F6amNKR3hQWXkvQzNqRGFOR3hYZDZ3TklJVkdSZ2hOUm53SjFsT2NBbk5aY2p2a295ckZ4Q3R0djMzMTQwUmlvT0ZKNGJDQ0dWdW9DYWcxdU9UVDIyMjIyZ0h3TFBZUS91Zjc5UVgrMEtJaWpkcm1wNjlSY3R6bVE9PSIsImF6cCI6IjZlNzQxNzJiLWJlNTYtNDg0My05ZmY0LWU2NmEzOWJiMTJlMyIsImF6cGFjciI6IjAiLCJuYW1lIjoiQWJlIExpbmNvbG4iLCJvaWQiOiI2OTAyMjJiZS1mZjFhLTRkNTYtYWJkMS03ZTRmN2QzOGU0NzQiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJhYmVsaUBtaWNyb3NvZnQuY29tIiwicmgiOiJJIiwic2NwIjoiYWNjZXNzX2FzX3VzZXIiLCJzdWIiOiJIS1pwZmFIeVdhZGVPb3VZbGl0anJJLUtmZlRtMjIyWDVyclYzeERxZktRIiwidGlkIjoiNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3IiwidXRpIjoiZnFpQnFYTFBqMGVRYTgyUy1JWUZBQSIsInZlciI6IjIuMCJ9.pj4N-w_3Us9DrBLfpCt
將適當的值提供給應用程式資訊清單 中的 accessTokenAcceptedVersion
設定,以設定應用程式的版本。 值 null
和 1
會導致 v1.0 權杖,而值 2
會導致 v2.0 權杖。
存取權杖要求涉及兩方:要求權杖的用戶端以及接受權杖的資源 (Web API)。 權杖的 aud
宣告中定義權杖預期的資源 (其「對象」 )。 用戶端會使用權杖,但不應該了解或嘗試進行剖析。 資源會接受權杖。
Microsoft 身分識別平台支援從任何版本端點簽發任何權杖版本。 例如,當 accessTokenAcceptedVersion
的值為 2
時,呼叫 v1.0 端點以取得該資源權杖的用戶端會收到 v2.0 存取權杖。
資源永遠擁有其權杖 (使用 aud
宣告),而且是唯一可以變更權杖詳細資料的應用程式。
存取權杖的預設存留期為變數。 簽發時,Microsoft 身分識別平台會將範圍介於 60-90 分鐘 (平均為 75 分鐘) 之間的隨機值指派為存取權杖的預設存留期。 此變異會將存取權杖需求分配至某個時間來改善服務恢復能力,以避免 Microsoft Entra ID 每小時尖峰流量暴增。
針對 Microsoft Teams 和 Microsoft 365 這類用戶端,未使用條件式存取的租用戶的預設存取權杖存留期為兩小時。
調整存取權杖的存留期,以控制用戶端應用程式讓應用程式工作階段到期,並要求使用者重新進行驗證的頻率,無論是無訊息方式或互動方式。 若要覆寫預設存取權杖存留期變化,請使用可設定的權杖存留期 (CTL) 。
將預設的權杖存留期變化套用至已啟用持續性存取評估 (CAE) 的組織。 即使組織使用 CTL 原則,仍套用預設權杖存留期變化。 長時間存留權杖存留期的預設權杖存留期範圍是從 20 到 28 小時。 存取權杖到期時,用戶端必須使用重新整理權杖,以無訊息方式來取得新的重新整理權杖和存取權杖。
使用條件式存取登入頻率 (SIF) 來強制執行登入頻率的組織,無法覆寫預設存取權杖存留期變化。 組織使用 SIF 時,用戶端認證提示之間的時間是權杖存留期 (範圍從 60-90 分鐘) 加上登入頻率間隔。
以下是預設權杖存留期差異如何搭配登入頻率運作的範例。 假設組織將登入頻率設定為每小時進行一次。 當權杖的存留期為 60-90 分鐘 (由於權杖存留期變化),實際的登入間隔會在 1 小時到 2.5 小時之間的任何時間發生。
如果權杖具有一小時存留期的使用者在 59 分鐘時執行互動式登入,則不會出現任何認證提示,因為登入低於 SIF 閾值。 如果新權杖的存留期為 90 分鐘,則使用者不會看到額外一個半小時的認證提示。 在無訊息續訂嘗試期間,Microsoft Entra ID 需要認證提示,因為工作階段長度總計已超過 1 小時的登入頻率設定。 在此範例中,由於 SIF 間隔和權杖存留期差異,認證提示之間的時差會是 2.5 小時。
並非所有應用程式都應該驗證權杖。 只有在特定情況下,應用程式才會驗證權杖:
Web API 必須驗證用戶端對其傳送的存取權杖, 而且只接受包含其中一個 AppId URI 作為 aud
宣告的權杖。
Web 應用程式必須先在混合式流程中使用使用者的瀏覽器來驗證傳送給這些應用程式的識別碼權杖,再允許存取使用者的資料或建立工作階段。
如果先前所述的案例都不適用,就不需要驗證權杖。 公用用戶端 (例如原生、桌面或單頁應用程式) 不會受益於驗證識別碼權杖,因為應用程式會直接與 IDP 通訊,其中 SSL 保護可確保識別碼權杖有效。 其不應該驗證存取權杖,因為存取權杖用於讓 Web API 進行驗證,而不是用戶端。
API 和 Web 應用程式只能驗證具有符合應用程式之 aud
宣告的權杖。 其他資源可能會有自訂權杖驗證規則。 例如,基於 Microsoft Graph 的權杖專屬格式,您無法根據這些規則來對其進行驗證。 驗證和接受適用於另一個資源的權杖是責任混淆 的問題範例。
如果應用程式需要驗證識別碼權杖或存取權杖,則應該先驗證權杖的簽章和簽發者是否符合 OpenID 探索文件中的值。
Microsoft Entra 中介軟體具有內建驗證存取權杖的功能,請參閱範例 ,以找到適當語言的範例。 也有數個第三方開放原始碼程式庫可用於 JWT 驗證。 如需驗證程式庫和程式碼範例的詳細資訊,請參閱 Microsoft Entra 驗證程式庫 。 如果 Web 應用程式或 Web API 位於 ASP.NET 或 ASP.NET Core 上,請使用 Microsoft.Identity.Web 來為您處理驗證。
若 Web 應用程式/API 正在驗證 v1.0 權杖 (ver
宣告 ="1.0"),需要從 v1.0 端點 (https://login.microsoftonline.com/{example-tenant-id}/.well-known/openid-configuration
) 讀取 OpenID Connect 中繼資料文件,即使針對 Web API 所設定的授權單位是 v2.0 授權單位也是一樣。
若 Web 應用程式/API 正在驗證 v2.0 權杖 (ver
宣告 ="2.0"),需要從 v2.0 端點 (https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration
) 讀取 OpenID Connect 中繼資料文件,即使針對 Web API 所設定的授權單位是 v1.0 授權單位也是一樣。
下列範例假設您的應用程式正在驗證 v2.0 存取權杖 (因此參考 OIDC 中繼資料文件和金鑰的 v2.0 版本)。 如果您驗證 v1.0 權杖,則只要移除 URL 中的 "/v2.0"。
OpenID Connect Core 表示「簽發者識別碼 [...] 必須完全符合 iss (簽發者) 宣告的值」。對於使用租用戶特定中繼資料端點的應用程式 (例如 https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/.well-known/openid-configuration
或 https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration
),這是需要的所有項目。
Microsoft Entra ID 具有租用戶無關的文件版本,可在 https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration 取得。 此端點會傳回簽發者值 https://login.microsoftonline.com/{tenantid}/v2.0
。 應用程式可以使用此與租用戶無關的端點,使用下列修改來驗證來自每個租用戶的權杖:
應用程式不應預期權杖中的簽發者宣告與中繼資料中的簽發者值完全相符,而是應該將簽發者中繼資料中的 {tenantid}
值取代為目前要求的目標 tenantid,然後檢查完全相符的項目。
應用程式應該使用從金鑰端點傳回的 issuer
屬性來限制金鑰的範圍。
具有類似 https://login.microsoftonline.com/{tenantid}/v2.0
的簽發者值的金鑰可以與任何相符的權杖簽發者搭配使用。
具有類似 https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0
的簽發者值的金鑰應該只搭配完全相符使用。
Microsoft Entra 租用戶無關的金鑰端點 (https://login.microsoftonline.com/common/discovery/v2.0/keys ) 會傳回如下的文件:
{
"keys":[
{"kty":"RSA","use":"sig","kid":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
]
}
使用 Microsoft Entra tenantid (tid
) 宣告作為信任界限 (而不是標準簽發者宣告) 的應用程式應該確保 tenant-id 宣告是 GUID,而且簽發者與 tenantid 相符。
針對會接受來自許多租用戶權杖的應用程式,使用租用戶無關的中繼資料會更有效率。
注意
使用 Microsoft Entra 租用戶無關的中繼資料時,應該在租用戶內解譯宣告,就像在標準 OpenID Connect 下,會於簽發者內解譯宣告一樣。 也就是說,即使 sub
相同,{"sub":"ABC123","iss":"https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0","tid":"aaaabbbb-0000-cccc-1111-dddd2222eeee"}
和 {"sub":"ABC123","iss":"https://login.microsoftonline.com/bbbbcccc-1111-dddd-2222-eeee3333ffff/v2.0","tid":"bbbbcccc-1111-dddd-2222-eeee3333ffff"}
還是可描述不同的使用者,因為類似 sub
的宣告會在簽發者/租用戶的內容中解譯。
JWT 包含三個區段 (以 .
字元分隔)。 第一個區段是標頭 ,第二個是主體 ,而第三個是簽章 。 使用簽章區段來評估權杖的真實性。
Microsoft Entra ID 會簽發使用業界標準非對稱加密演算法所簽署的權杖,例如 RS256。 JWT 標頭包含用來簽署權杖的金鑰和加密方法相關資訊:
{
"typ": "JWT",
"alg": "RS256",
"x5t": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a",
"kid": "H4iJ5kL6mN7oP8qR9sT0uV1wX2yZ3a"
}
alg
宣告指示用來簽署權杖的演算法,而 kid
宣告則指示用來驗證權杖的特定公開金鑰。
在任何指定的時間點,Microsoft Entra ID 可能會使用一組特定公開與私密金鑰組的任何其中一個金鑰組來簽署識別碼權杖。 Microsoft Entra ID 會定期輪替可能的金鑰組,因此會撰寫應用程式以自動處理這些金鑰變更。 檢查 Microsoft Entra ID 所使用公開金鑰的更新合理頻率是每 24 小時。
使用位於下列位置的 OpenID Connect 中繼資料文件 ,以取得驗證簽章所需的簽署金鑰資料:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
下列資訊說明中繼資料文件:
為 JSON 物件,其中包含數項實用資訊,例如執行 OpenID Connect 驗證所需的各種端點位置。
包含 jwks_uri
,且會提供對應至用來簽署權杖之私密金鑰的公開金鑰集位置。 位於 jwks_uri
的 JSON Web 金鑰 (JWK) 包含在該特定時間點使用的所有公開金鑰資訊。 RFC 7517 描述 JWK 格式。 應用程式可以使用 JWT 標頭中的 kid
宣告來選取此文件中的公開金鑰,這會對應至用來簽署特定權杖的私密金鑰。 接著可使用正確的公開金鑰和所指定演算法來執行簽章驗證。
注意
使用 kid
宣告來驗證權杖。 雖然 v1.0 權杖同時包含 x5t
和 kid
宣告,但 v2.0 權杖只包含 kid
宣告。
執行簽章驗證已超出本文件的範圍。 如有需要,有許多開放原始碼程式庫可用來協助驗證簽章。 不過,Microsoft 身分識別平台對於標準具備一個權杖簽署延伸模組,即自訂簽署金鑰。
如果應用程式因使用宣告對應 功能而具有自訂簽署金鑰,請附加包含應用程式識別碼的 appid
查詢參數。 若要進行驗證,請使用指向應用程式的簽署金鑰資訊的 jwks_uri
。 例如:https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=00001111-aaaa-2222-bbbb-3333cccc4444
包含內容為 https://login.microsoftonline.com/{tenant}/discovery/keys?appid=00001111-aaaa-2222-bbbb-3333cccc4444
的 jwks_uri
。
可驗證識別碼權杖的 Web 應用程式以及可驗證存取權杖的 Web API 需要針對下列項目來驗證權杖的簽發者 (iss
宣告):
OpenID Connect 中繼資料文件中提供、與應用程式設定 (授權) 相關聯的簽發者。 要驗證的中繼資料文件取決於:
權杖的租用戶識別碼 (tid
宣告),
簽署金鑰的簽發者。
OpenID Connect Core 表示「簽發者識別碼 [...] 必須完全符合 iss
(簽發者) 宣告的值」。針對使用租用戶特定中繼資料端點的應用程式,例如 https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configuration
或 https://login.microsoftonline.com/contoso.onmicrosoft.com/v2.0/.well-known/openid-configuration
。
單一租用戶應用程式是支援下列項目的應用程式:
一個組織目錄中的帳戶 (僅限 example-tenant-id ):https://login.microsoftonline.com/{example-tenant-id}
僅限個人 Microsoft 帳戶:https://login.microsoftonline.com/consumers
(「取用者」 是租用戶 9188040d-6c67-4c5b-b112-36a304b66dad 的暱稱)
Microsoft Entra ID 也支援多租用戶應用程式。 這些應用程式支援:
任何組織目錄中的帳戶 (任何 Microsoft Entra 目錄):https://login.microsoftonline.com/organizations
任何組織目錄 (任何 Microsoft Entra 目錄) 中的帳戶,以及個人 Microsoft 帳戶 (例如 Skype、XBox):https://login.microsoftonline.com/common
針對這些應用程式,Microsoft Entra ID 會分別在 https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
和 https://login.microsoftonline.com/organizations/v2.0/.well-known/openid-configuration
上公開與租用戶無關的 OIDC 文件版本。 這些端點會傳回簽發者值,這是由 tenantid
參數化的範本:https://login.microsoftonline.com/{tenantid}/v2.0
。 應用程式可以使用這些與租用戶無關的端點,使用下列規定來驗證來自每個租用戶的權杖:
驗證簽署金鑰簽發者
應用程式不應預期權杖中的簽發者宣告與中繼資料中的簽發者值完全相符,而是應該將簽發者中繼資料中的 {tenantid}
值取代為目前要求的目標租用戶識別碼,然後檢查完全相符的項目 (權杖的 tid
宣告)。
驗證 tid
宣告是否為 GUID,而 iss
宣告的格式為 https://login.microsoftonline.com/{tid}/v2.0
,其中的 {tid}
為確切的 tid
宣告。 此驗證會將租用戶繫結回簽發者,並回到建立信任鏈結的簽署金鑰範圍。
在找到與宣告主體相關聯的資料時,使用 tid
宣告。 換句話說,tid
宣告必須是用來存取使用者金鑰的一部分。
使用 v2.0 租用戶無關中繼資料的應用程式需要驗證簽署金鑰簽發者。
如前所述,從 OpenID Connect 文件,您的應用程式會存取用來簽署權杖的金鑰。 其會存取 OpenIdConnect 文件的 jwks_uri 屬性中公開的 URL,以取得對應的金鑰文件。
"jwks_uri": "https://login.microsoftonline.com/{example-tenant-id}/discovery/v2.0/keys",
此 {example-tenant-id}
值可以由 GUID、網域名稱或「一般」 、「組織」 和「取用者」 取代
Azure AD v2.0 所公開的 keys
文件會針對每個金鑰包含使用此簽署金鑰的簽發者。 例如,租用戶無關的「一般」金鑰端點 https://login.microsoftonline.com/common/discovery/v2.0/keys
會傳回如下的文件:
{
"keys":[
{"kty":"RSA","use":"sig","kid":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","x5t":"A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","x5t":"C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
{"kty":"RSA","use":"sig","kid":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","x5t":"E3fH4iJ5kL6mN7oP8qR9sT0uV1wX2y","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
]
}
應用程式應該使用金鑰文件的 issuer
屬性 (與用來簽署權杖的金鑰相關聯),以限制金鑰的範圍:
具有類似 https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0
GUID 的簽發者值的金鑰,只有在權杖中的 iss
宣告完全符合值時才應該使用。
具有類似 https://login.microsoftonline.com/{tenantid}/v2.0
範本化簽發者值的索引鍵,只有在權杖中的 iss
宣告在取代 {tenantid}
預留位置的權杖中的 tid
宣告之後才應該使用。
針對會接受來自許多租用戶權杖的應用程式,使用租用戶無關的中繼資料會更有效率。
注意
使用 Microsoft Entra 租用戶無關的中繼資料時,應該在租用戶內解譯宣告,就像在標準 OpenID Connect 下,會於簽發者內解譯宣告一樣。 也就是說,即使 sub
相同,{"sub":"ABC123","iss":"https://login.microsoftonline.com/{example-tenant-id}/v2.0","tid":"{example-tenant-id}"}
和 {"sub":"ABC123","iss":"https://login.microsoftonline.com/{another-tenand-id}/v2.0","tid":"{another-tenant-id}"}
還是會描述不同的使用者,因為類似 sub
的宣告會在簽發者/租用戶的內容中解譯。
以下是一些虛擬程式碼,可總結如何驗證簽發者和簽署金鑰簽發者:
從已設定的中繼資料 URL 擷取金鑰
檢查權杖是否已其中一個已發佈的金鑰簽署,如果不是,則會失敗
根據子標頭識別中繼資料中的金鑰。 檢查附加至中繼資料文件中金鑰的「簽發者」屬性:var issuer = metadata["kid"].issuer;
if (issuer.contains("{tenantId}", CaseInvariant)) issuer = issuer.Replace("{tenantid}", token["tid"], CaseInvariant);
if (issuer != token["iss"]) throw validationException;
if (configuration.allowedIssuer != "*" && configuration.allowedIssuer != issuer) throw validationException;
var issUri = new Uri(token["iss"]);
if (issUri.Segments.Count < 1) throw validationException;
if (issUri.Segments[1] != token["tid"]) throw validationException;