共用方式為


Microsoft 身分識別平台內的存取權杖

存取權杖可讓用戶端安全地呼叫受保護的 Web API。 Web API 使用存取權杖來執行驗證和授權。

根據 OAuth 規格,存取權杖是沒有固定格式的不透明字串。 有些身分識別提供者 (IDP) 會使用 GUID,而其他提供者則會使用已加密的 Blob。 存取權杖的格式取決於接受權杖的 API 設定。

開發人員在 Microsoft 身分識別平台上註冊的自訂 API 可以選擇兩種不同格式的 JSON Web 權杖 (JWT),稱為 v1.0v2.0。 Microsoft 所開發的 API (例如 Microsoft Graph 或 Azure 中的 API) 具有其他專屬權杖格式。 無法驗證的這些專屬格式,可能是加密的權杖、JWT 或類似特殊 JWT 權杖。

權杖的內容僅適用於 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 設定,以設定應用程式的版本。 值 null1 會導致 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,其會為您處理驗證。

v1.0 和 v2.0 權杖

  • 當您的 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-configurationhttps://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。 應用程式可以使用此與租用戶無關的端點,使用下列修改來驗證來自每個租用戶的權杖:

  1. 應用程式不應預期權杖中的簽發者宣告與中繼資料中的簽發者值完全相符,而是應該將簽發者中繼資料中的 {tenantid} 值取代為目前要求的目標 tenantid,然後檢查完全相符的項目。

  2. 應用程式應該使用從金鑰端點傳回的 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":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
        {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
        {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","n":"rv0...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0"}
      ]
    }
    
  3. 使用 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": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk",
  "kid": "iBjL1Rcqzhiy4fpxIxdZqohM2Yk"
}

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

提示

在瀏覽器中嘗試此項目:URL

下列資訊說明中繼資料文件:

  • 為 JSON 物件,其中包含數項實用資訊,例如執行 OpenID Connect 驗證所需的各種端點位置。
  • 包含 jwks_uri,且會提供對應至用來簽署權杖之私密金鑰的公開金鑰集位置。 位於 jwks_uri 的 JSON Web 金鑰 (JWK) 包含在該特定時間點使用的所有公開金鑰資訊。 RFC 7517 描述 JWK 格式。 應用程式可以使用 JWT 標頭中的 kid 宣告來選取此文件中的公開金鑰,這會對應至用來簽署特定權杖的私密金鑰。 接著可使用正確的公開金鑰和所指定演算法來執行簽章驗證。

注意

使用 kid 宣告來驗證權杖。 雖然 v1.0 權杖同時包含 x5tkid 宣告,但 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-3333cccc4444jwks_uri

驗證簽發者

驗證識別碼權杖的 Web 應用程式,以及驗證存取權杖的 Web API,必須針對下列項目驗證權杖 (iss 宣告) 的簽發者:

  1. OpenID Connect 中繼資料文件中提供、與應用程式設定 (授權) 相關聯的簽發者。 要驗證的中繼資料文件取決於:
    • 權杖的版本
    • 您的應用程式支援的帳戶。
  2. 權杖的租用戶識別碼 (tid 宣告),
  3. 簽署金鑰的簽發者。

單一租用戶應用程式

OpenID Connect Core 表示「簽發者識別碼 [...] 必須完全符合 iss (簽發者) 宣告的值」。針對使用租用戶特定中繼資料端點的應用程式,例如 https://login.microsoftonline.com/{example-tenant-id}/v2.0/.well-known/openid-configurationhttps://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-configurationhttps://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":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","x5t":"jS1Xo1OWDj_52vbwGNgvQO2VzMc","n":"spv...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","x5t":"2ZQpJ3UpbjAYXYGaXEJl8lV0TOI","n":"wEM...","e":"AQAB","x5c":["MIID..."],"issuer":"https://login.microsoftonline.com/{tenantid}/v2.0"},
    {"kty":"RSA","use":"sig","kid":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","x5t":"yreX2PsLi-qkbR8QDOmB_ySxp8Q","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 的宣告會在簽發者/租用戶的內容中解譯。

概括回顧

以下是一些虛擬程式碼,可總結如何驗證簽發者和簽署金鑰簽發者:

  1. 從已設定的中繼資料 URL 擷取金鑰
  2. 檢查權杖是否已其中一個已發佈的金鑰簽署,如果不是,則會失敗
  3. 根據子標頭識別中繼資料中的金鑰。 檢查附加至中繼資料文件中金鑰的「簽發者」屬性:
    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;
    

另請參閱

下一步