共用方式為

了解主要刷新權杖（PRT）

  • 發行項

主要重新整理令牌（PRT）是 Microsoft Entra 驗證在支援版本的 Windows、iOS 和 Android 中的重要元素。 本文說明如何在 Windows 10 或更新版本裝置上發出、使用及保護 PRT、增強安全性，以及跨應用程式啟用單一登錄（SSO）。

本文假設您已經瞭解 Microsoft Entra ID 中可用的不同裝置狀態，以及單一登錄在 Windows 中的運作方式。 如需Microsoft Entra標識符中裝置的詳細資訊，請參閱 Microsoft Entra 標識符中的裝置管理為何？。

重要術語和元件

下列 Windows 元件在要求和使用 PRT 方面扮演著重要角色：

  • 雲端驗證提供者 (CloudAP)：CloudAP 是 Windows 登入的新式驗證提供者，可驗證使用者是否登入 Windows 10 或較新的裝置。 CloudAP 提供一個外掛程式架構，讓識別提供者能夠以此為建置基礎，使用該識別提供者的認證對 Windows 啟用驗證。
  • Web 帳戶管理員 (WAM)：WAM 是 Windows 10 或較新裝置上的預設權杖代理程式。 WAM 也提供一個外掛程式架構，讓識別提供者能夠以此為建置基礎，並對依賴該識別提供者的應用程式啟用 SSO。
  • Microsoft Entra CloudAP 外掛程式：以 CloudAP 架構為基礎的 Microsoft Entra 專屬外掛程式，可在 Windows 登入期間使用 Microsoft Entra ID 驗證使用者認證。
  • Microsoft Entra WAM 外掛程式：以 WAM 架構為基礎的 Microsoft Entra 專屬外掛程式，可對依賴 Microsoft Entra ID 進行驗證的應用程式啟用 SSO。
  • Dsreg：Windows 10 或更新版本上的 Microsoft Entra 專屬元件，可針對所有裝置狀態處理裝置註冊程序。
  • 信賴平台模組 (TPM)：TPM 是裝置內建的硬體元件，可為使用者和裝置祕密提供硬體型安全功能。 如需更多詳細資料，請參閱信賴平台模組技術概觀。

PRT 包含哪些內容？

PRT 包含大部分 Microsoft Entra ID 更新權杖中可找到的宣告。 此外，PRT 中還包含一些裝置特定的聲明。 它們如下：

  • 裝置識別碼：PRT 的發佈對象是特定裝置上的使用者。 裝置識別碼宣告 deviceID 用來確定 PRT 是發放到哪個裝置上的。 此宣告會在稍後發給透過 PRT 取得的權杖。 裝置識別碼宣告的用途是根據裝置狀態或合規性來決定條件式存取的授權。
  • 工作階段金鑰：工作階段金鑰是加密的對稱金鑰，由 Microsoft Entra 驗證服務產生，並且會作為 PRT 的一部份來發出。 當使用 PRT 來取得其他應用程式的權杖時，工作階段金鑰會充當擁有權的證明。 在 Windows 10 或更新的 Microsoft Entra 加入裝置或 Microsoft Entra 混合式加入裝置上，工作階段金鑰會在存在超過 30 天後進行輪替。

我可以看到 PRT 中的內容嗎？

PRT 是從 Microsoft Entra 傳送的不透明 Blob，任何用戶端元件都不會知道其內容。 您無法看到 PRT 的內部。

PRT 如何發行？

裝置註冊是在 Microsoft Entra ID 中進行裝置型驗證時的必要條件。 PRT 只會發給已註冊裝置上的使用者。 如需深入了解裝置註冊的詳細資料，請參閱 Windows Hello 企業版和裝置註冊一文。 在裝置註冊期間，dsreg 元件會產生兩組密碼編譯金鑰組：

  • 裝置金鑰 (dkpub/dkpriv)
  • 傳輸金鑰 (tkpub/tkpriv)

如果裝置具有有效且正常運作的 TPM，則私密金鑰會繫結至裝置的 TPM，而公開金鑰則會在裝置註冊過程中傳送至 Microsoft Entra ID。 在 PRT 要求期間，這些金鑰會用來驗證裝置狀態。

在兩種情況下，當 Windows 10 或更新版本的裝置進行使用者驗證時，會發出 PRT：

  • Microsoft Entra 加入或 Microsoft Entra 混合式加入：在 Windows 登入期間，PRT 會在使用者使用其組織認證登入時發出。 PRT 會以所有 Windows 10 或更新版本支援的認證 (例如，密碼和 Windows Hello 企業版) 來發出。 在此情境中，Microsoft Entra CloudAP 插件是 PRT 的主要權威。
  • Microsoft Entra 已註冊的裝置：當使用者將次要工作帳戶新增至其 Windows 10 或較新的裝置時，會發出 PRT。 使用者可以透過兩種不同的方式，將帳戶新增至 Windows 10 或更新版本 -
    • 在登入應用程式 (例如 Outlook) 之後，透過 [允許我的組織管理我的裝置] 提示來新增帳戶
    • 從 [設定]>[帳戶]>[存取公司或學校帳戶]>[連線] 中新增帳戶

在 Microsoft Entra 裝置註冊情境中，由於不使用此 Microsoft Entra 帳戶進行 Windows 登入，因此 Microsoft Entra WAM 外掛程式是 PRT 的主要權威。

注意事項

非Microsoft識別提供者必須支援 WS-Trust 通訊協定，才能在 Windows 10 或更新版本裝置上啟用 PRT 發行。 如果沒有 WS-Trust，便無法在 Microsoft Entra 混合加入或 Microsoft Entra 加入的裝置上發行 PRT 給使用者。 在 AD FS 上，只需要使用者名稱混合端點。 在 AD FS 上，如果在 Windows 登入期間使用 smartcard/certificate，則需要 certificatemixed 端點。 adfs/services/trust/2005/windowstransport 和 adfs/services/trust/13/windowstransport 都只能啟用為內部網路對應端點，且不得透過 Web 應用程式 Proxy 公開為內部網路對應端點。

注意

Microsoft發出 PRT 時，不會評估 Entra 條件式存取原則。

注意

我們不支持發行和更新 Microsoft Entra PRT 的非Microsoft認證提供者。

PRT 的存留期為何？

PRT 在發出之後的有效時間為 14 天，而且只要使用者積極使用裝置，PRT 就會持續更新。

如何使用 PRT？

Windows 中有兩個主要元件會使用 PRT：

  • Microsoft Entra CloudAP 外掛程式：在 Windows 登入期間，Microsoft Entra CloudAP 外掛程式會使用使用者所提供的認證，向 Microsoft Entra ID 要求 PRT。 其也會快取 PRT，以在使用者無法存取網際網路連線時啟用快取登入。
  • Microsoft Entra WAM 外掛程式：當使用者嘗試存取應用程式時，Microsoft Entra WAM 外掛程式會使用 PRT 來啟用 Windows 10 或更新版本上的 SSO。 針對依賴 WAM 進行權杖要求的應用程式，Microsoft Entra WAM 外掛程式會使用 PRT 來向其要求重新整理和存取權杖。 其也會藉由將 PRT 插入瀏覽器要求中，在瀏覽器上啟用 SSO。 在 Microsoft Edge (原生)、Chrome (透過 Windows 10 帳戶) 或 Mozilla Firefox v91 + (Firefox Windows SSO 設定) 上可支援 Windows 10 或更新版本中的瀏覽器 SSO

    注意

    當使用者具有相同 Microsoft Entra 租用戶中的兩個帳戶登入瀏覽器應用程式的情況下，主要帳戶的 PRT 所提供的裝置驗證也會自動套用至第二個帳戶。 因此，第二個帳戶也會滿足租用戶上任何基於裝置的條件存取策略。

PRT 更新的方法是什麼？

PRT 會以兩種不同的方式更新：

  • Microsoft Entra CloudAP 外掛程式每 4 小時：在 Windows 登入期間，CloudAP 外掛程式會每 4 小時更新 PRT。 如果使用者在此期間沒有因特網連線，CloudAP 外掛程式會在裝置連線到因特網之後更新 PRT，並完成新的 Windows 登入。
  • 應用程式權杖要求期間的 Microsoft Entra WAM 外掛程式：WAM 外掛程式會啟用應用程式的無訊息權杖要求，藉此在 Windows 10 或更新版本裝置上啟用 SSO。 WAM 外掛程式可以透過兩種不同的方式，在這些權杖要求期間更新 PRT：
    • 應用程式在無需用戶交互的情況下向 WAM 請求存取權杖，但該應用程式沒有可用的重新整理權杖。 在此情況下，WAM 會使用 PRT 來要求應用程式的權杖，並在回應中取得新的 PRT。
    • 應用程式向 WAM 要求存取權杖，但 PRT 無效或 Microsoft Entra ID 需要額外的授權 (例如，Microsoft Entra 多重要素驗證)。 在此情況下，WAM 會起始需要使用者進行重新驗證或提供額外驗證的互動式登入，而新的 PRT 會在成功驗證時發出。

在 AD FS 環境中，不需要直接看到網域控制站就能更新 PRT。 PRT 更新只需要在 Proxy 上使用 WS-Trust 協定啟用 /adfs/services/trust/2005/usernamemixed 和 /adfs/services/trust/13/usernamemixed 端點。

Windows 傳輸端點僅在變更密碼時才需要密碼驗證，但 PRT 更新並不需要。

注意

Microsoft更新 PRT 時，不會評估 Entra 條件式存取原則。

主要考量

  • 在 Microsoft Entra 加入裝置和 Microsoft Entra 混合式加入裝置中，CloudAP 外掛程式是 PRT 的主要授權單位。 如果在以 WAM 為基礎的權杖要求期間更新 PRT，則 PRT 會傳送回 CloudAP 外掛程式，該程式會在接受 PRT 之前，向 Microsoft Entra ID 驗證 PRT 的有效性。

Android 平台：

  • PRT 有效期限為 90 天，只要裝置仍在使用中，即會持續更新 PRT。 不過，如果裝置未在使用中，有效期只有 14 天。
  • PRT 只會在原生應用程式驗證期間發出及更新。 PRT 不會在瀏覽器會話期間更新或發出。
  • 不需要裝置註冊 (Workplace Join)，即可取得 PRT 和啟用 SSO。
  • 在沒有裝置註冊的情況下取得的 PRT，無法滿足依賴裝置狀態或合規性的條件式存取授權準則。

PRT 如何受到保護？

保護 PRT 的方式是將其繫結至使用者已登入的裝置。 Microsoft Entra ID 和 Windows 10 或更新版本會透過下列方法啟用 PRT 保護：

  • 第一次登入期間：在第一次登入期間，PRT 會透過使用在裝置註冊期間加密生成的裝置金鑰進行要求簽署來發出。 在其 TPM 有效且可運作的裝置上，裝置金鑰會受到 TPM 的保護，以防止任何惡意存取。 如果無法驗證對應的裝置金鑰簽章，則不會發出 PRT。
  • 在 Token 要求和更新期間：發出 PRT 時，Microsoft Entra ID 也會對裝置發出加密的會話金鑰。 其會使用產生的公開傳輸金鑰 (tkpub) 進行加密，並在裝置註冊過程中傳送至 Microsoft Entra ID。 此工作階段金鑰只能由 TPM 所保護的私人傳輸金鑰 (tkpriv) 進行解密。 對於所有傳送至 Microsoft Entra ID 的請求，工作階段金鑰是擁有權證明 (POP) 金鑰。 會話金鑰也會受到 TPM 的保護，而且其他作業系統元件無法存取該金鑰。 此工作階段金鑰會透過 TPM 安全地簽署權杖要求或 PRT 更新要求，因此無法遭到篡改。 Microsoft Entra 使任何不是由對應工作階段金鑰簽署的來自裝置的要求無效。

我們可以藉由使用 TPM 保護這些金鑰來強化 PRT 的安全性，防止惡意執行者嘗試竊取金鑰或重新執行 PRT。 因此，使用 TPM 可以顯著提升 Microsoft Entra 加入裝置、Microsoft Entra 混合加入裝置和 Microsoft Entra 註冊裝置的安全性，以防止認證遭竊。 為了擁有更好的效能和可靠性，我們建議您針對 Windows 10 或更新版本上所有 Microsoft Entra 裝置註冊案例使用 TPM 2.0。 在 Windows 10、1903 更新之後，Microsoft Entra 識別碼不會因為可靠性問題而針對上述任何密鑰使用 TPM 1.2。

如何保護應用程式令牌和瀏覽器 Cookie？

應用程式權杖：當應用程式透過 WAM 要求權杖時，Microsoft Entra ID 會發出重新整理權杖和存取權杖。 不過，WAM 只會將存取權杖傳回給應用程式，並透過使用者的資料保護應用程式開發介面 (DPAPI) 金鑰來加密重新整理權杖，進而在其快取中保護重新整理權杖。 WAM 透過使用工作階段金鑰簽署請求，安全地使用刷新權杖以簽發額外的存取權杖。 DPAPI 金鑰是由 Microsoft Entra 本身的 Microsoft Entra ID 型對稱金鑰所保護。 當裝置需要使用 DPAPI 金鑰來解密使用者設定檔時，Microsoft Entra ID 會提供由工作階段金鑰加密的 DPAPI 金鑰，然後由 CloudAP 外掛程式要求 TPM 進行解密。 此功能確保刷新權杖的安全性一致性，避免應用程式使用自己的保護機制。

瀏覽器 Cookie：在 Windows 10 或更新版本中，Microsoft Entra ID 以原生方式在 Internet Explorer 和 Microsoft Edge 中支援瀏覽器 SSO、在 Google Chrome 中透過 Windows 10 帳戶擴充功能支援瀏覽器 SSO，以及在 Mozilla Firefox v91+ 中透過瀏覽器設定支援瀏覽器 SSO。 安全性不只是用來保護 Cookie，也會保護 Cookie 的目的地端點。 瀏覽器 Cookie 的保護方式與 PRT 相同，也是利用工作階段金鑰來簽署和保護 Cookie。

當使用者起始瀏覽器互動時，瀏覽器 (或擴充功能) 會叫用 COM 原生用戶端主機。 原生用戶端主機可確保頁面是來自其中一個允許的網域。 瀏覽器可以將其他參數傳送至原生用戶端主機 (包括 nonce)，不過原生用戶端主機可保證主機名稱的正確性。 原生用戶端主機會向 CloudAP 外掛程式要求 PRT Cookie，該程式會使用 TPM 保護的工作階段金鑰來建立及簽署此 Cookie。 由於 PRT Cookie 是由工作階段金鑰簽署，因此難以篡改。 此 PRT Cookie 會包含在要求標頭中，以供 Microsoft Entra ID 用來驗證其來源裝置。 如果使用 Chrome 瀏覽器，則只有在原生用戶端主機資訊清單中明確定義的擴充功能可以叫用它，這樣做可以防止任意擴充功能提出這些要求。 Microsoft Entra ID 會在驗證 PRT Cookie 之後，向瀏覽器發出工作階段 Cookie。 此工作階段 Cookie 也包含與 PRT 發出相同的工作階段金鑰。 在後續要求期間，工作階段金鑰會進行驗證，以有效地將 Cookie 繫結至裝置，並防止從其他地方重新執行。

PRT 何時會取得 MFA 聲明？

PRT 可以在特定情境中取得多重身份驗證宣告。 當使用基於 MFA 的 PRT 來要求應用程式的權杖時，MFA 宣告會轉移到這些應用程式的權杖上。 這項功能可避免每個需要 MFA 的應用程式遇到 MFA 方面的問題，為使用者提供順暢的體驗。 PRT 可以透過以下方式取得 MFA 聲明：

  • 使用 Windows Hello 企業版登入：Windows Hello 企業版會取代密碼，並使用密碼編譯金鑰來提供強式雙重要素驗證。 Windows Hello 企業版專屬於裝置上的使用者，而且本身需要 MFA 才能佈建。 當使用者使用 Windows Hello 企業版登入時，使用者的 PRT 就會取得 MFA 宣告。 如果智慧卡驗證從 ADFS 產生 MFA 宣告，則此狀況也適用於使用智慧卡登入的使用者。
    • 由於 Windows Hello 企業版被視為多重要素驗證，因此當 PRT 本身重新整理時，MFA 宣告會更新，這樣當使用者使用 Windows Hello 企業版登入時，MFA 的有效期間會延長。
  • WAM 互動式登入期間的多重因素驗證（MFA）：在透過 WAM 進行權杖要求的期間，如果使用者必須執行多重因素驗證（MFA）來存取應用程式，則在此互動期間更新的 PRT 就會嵌入 MFA 宣告。
    • 在此情況下，MFA 宣告不會持續更新，因此 MFA 持續時間是以目錄上設定的存留期為依據。
    • 當先前存在的 PRT 和 RT 用來存取應用程式時，PRT 和 RT 將被視為第一個驗證證明。 新的 RT 將需要第二個證明和印入的 MFA 聲明。 此程序也會發出新的 PRT 和 RT。

Windows 10 或更新版本會為每個憑證維護一份 PRT 的分區清單。 因此，針對 Windows Hello for Business、密碼或智慧卡，每個都會有相應的 PRT。 此分割可確保 MFA 聲明根據使用的認證被隔離，並避免在令牌請求期間混淆。

注意

使用密碼登入 Windows 10 或更新版本的 Microsoft Entra 加入裝置或 Microsoft Entra 混合式加入裝置時，當與 PRT 相關聯的會話金鑰進行輪替後，在 WAM 互動式登入期間可能需要 MFA。

PRT 如何會失效？

在下列案例中，PRT 會失效：

  • 無效使用者：如果 Microsoft Entra ID 中的使用者遭到刪除或停用，則他們的 PRT 會失效，且無法用來取得應用程式的權杖。 如果已刪除或停用的使用者在之前已登入裝置，則快取登入會將其記錄在其中，直到 CloudAP 發現其無效狀態為止。 一旦 CloudAP 判定使用者無效，就會封鎖後續的登入。 系統會自動封鎖無效使用者，使其無法登入未快取其認證的新裝置。
  • 無效裝置：如果 Microsoft Entra ID 中的裝置遭到刪除或停用，則在該裝置上取得的 PRT 會失效，且無法用來取得其他應用程式的權杖。 如果使用者已登入無效裝置，他們可以繼續執行此動作。 但裝置上的所有權杖都已失效，導致使用者無法透過該裝置的 SSO 訪問任何資源。
  • 密碼變更：如果使用者以密碼取得 PRT，則當使用者變更其密碼時，Microsoft Entra ID 會使 PRT 失效。 密碼變更會致使使用者取得新的 PRT。 此失效狀況可能會以兩種不同的方式發生：
    • 如果使用者使用新密碼登入 Windows，CloudAP 會捨棄舊的 PRT，並要求 Microsoft Entra ID 使用新的密碼來發出新的 PRT。 如果使用者沒有網際網路連線，將會無法驗證新的密碼，Windows 可能會要求使用者輸入舊密碼。
    • 如果使用者以舊密碼登入或在登入 Windows 之後變更其密碼，則任何以 WAM 為基礎的權杖要求都會使用舊的 PRT。 在此情況下，系統會提示使用者在 WAM 權杖要求期間進行重新驗證，並發出新的 PRT。
  • TPM 問題：有時候，裝置的 TPM 可能會折損或失敗，而導致無法存取 TPM 保護的金鑰。 在此情況下，裝置將無法取得 PRT 或使用現有的 PRT 來請求權杖，因為其無法證明擁有加密金鑰。 因此，Microsoft Entra ID 會讓任何現有的 PRT 都失效。 Windows 10 會在偵測到失敗時起始復原流程，以使用新的密碼編譯金鑰來重新註冊裝置。 使用 Microsoft Entra 混合加入時，就像初次註冊一樣，復原會在沒有使用者輸入的情況下自動進行。 若是 Microsoft Entra 加入裝置或 Microsoft Entra 註冊裝置，則必須由在裝置上具有系統管理員權限的使用者執行復原。 在此情況下，復原流程會由引導使用者成功復原裝置的 Windows 提示字元來起始。

詳細流程

下圖說明發出、更新和使用 PRT 來要求應用程式存取權杖時的詳細資料。 此外，這些步驟也會說明這些互動期間如何套用先前提及的安全性機制。

第一次登入期間的 PRT 發佈

首次登入時的 PRT 發佈詳細流程

注意

在 Microsoft Entra 加入裝置中，會先同步進行 Microsoft Entra PRT 發行 (步驟 A-F)，使用者才可登入 Windows。 在 Microsoft Entra 混合式加入裝置中，內部部署 Active Directory 是主要權威。 所以，使用者能夠在取得 TGT 後登入 Microsoft Entra 混合加入的 Windows，而 PRT 的發行則是以非同步方式進行。 此案例不適用於 Microsoft Entra 註冊的裝置，因為登入不會使用 Microsoft Entra 認證。

注意

在 Microsoft Entra 混合式加入 Windows 環境中，PRT 的發行會以非同步方式發生。 PRT 的發行可能會因為同盟提供者的問題而失敗。 當使用者嘗試存取雲端資源時，此失敗可能會導致登入問題。 務必要與聯盟提供者針對此情境進行故障排除。

步驟 描述
A 使用者在登入 UI 中輸入其密碼。 LogonUI 會將驗證緩衝區中的認證傳遞給 LSA，這會在內部將其傳遞給 CloudAP。 CloudAP 會將此要求轉送至 CloudAP 外掛程式。
B CloudAP 外掛程式會起始領域探索要求，以識別使用者的識別提供者。 如果使用者的租戶已設定同盟提供者，Microsoft Entra ID 會傳回同盟提供者的中繼資料交換 (MEX) 端點。 如果不是，Microsoft Entra ID 會傳回使用者已受管理，表示使用者可以使用 Microsoft Entra ID 進行驗證。
C 如果使用者受到管理，CloudAP 會從 Microsoft Entra ID 取得 nonce。 如果使用者是同盟的，CloudAP 外掛程式會以使用者認證向同盟提供者要求安全性聲明標記語言 (SAML) 權杖。 在將 SAML 權杖傳送至 Microsoft Entra ID 之前，系統會要求提供 nonce。
D CloudAP 外掛程式會使用使用者的認證、nonce 和代理程式範圍來建立驗證要求，並使用裝置金鑰 (dkpriv) 簽署要求，然後將其傳送至 Microsoft Entra ID。 在同盟環境中，CloudAP 外掛程式會使用同盟提供者所傳回的 SAML 權杖，而不是使用者的認證。
E Microsoft Entra ID 會驗證使用者認證、nonce 和裝置簽章，確認裝置在租用戶中是有效的，並發出加密的 PRT。 除了 PRT 之外，Microsoft Entra ID 也會發出對稱金鑰，稱為會議金鑰，由 Microsoft Entra ID 使用傳輸金鑰 (tkpub) 對其進行加密。 此外，工作階段金鑰也會內嵌在 PRT 中。 此會話金鑰在使用 PRT 進行後續要求時，作為擁有權證明 (PoP) 金鑰。
F CloudAP 插件會將加密的 PRT 和工作階段金鑰傳遞至 CloudAP。 CloudAP 會要求 TPM 使用傳輸金鑰 (tkpriv) 來解密會話金鑰，並使用 TPM 自己的金鑰來重新對其加密。 CloudAP 會將加密的工作階段金鑰連同 PRT 一起儲存在雲快取中。

後續登入中的 PRT 更新

後續登入中的 PRT 更新

步驟 描述
A 使用者在登入 UI 中輸入其密碼。 LogonUI 會將驗證緩衝區中的認證傳遞給 LSA，這會在內部將其傳遞給 CloudAP。 CloudAP 會將此要求轉送至 CloudAP 外掛程式。
B 如果使用者先前已登入該工作階段，Windows 就會啟動快取登入，並驗證使用者的認證以完成登入。 每 4 小時，CloudAP 外掛程式就會以非同步方式起始 PRT 更新。
C CloudAP 外掛程式會起始領域探索要求，以識別使用者的識別提供者。 如果使用者的租用戶已設定同盟提供者，Microsoft Entra ID 會傳回同盟提供者的中繼資料交換 (MEX) 端點。 如果不是，Microsoft Entra ID 會傳回使用者已受管理，表示使用者可以使用 Microsoft Entra ID 進行驗證。
D 如果使用者屬於聯盟，CloudAP 插件會以使用者的認證向同盟提供者要求 SAML 權杖。 在傳送 SAML 權杖至 Microsoft Entra ID 之前，會要求 nonce。 如果使用者是受管理的，CloudAP 會直接從 Microsoft Entra ID 取得 nonce。
E CloudAP 外掛程式會使用使用者的認證、nonce 和現有 PRT 來建立驗證要求，並使用會話金鑰簽署要求，然後將其傳送至 Microsoft Entra ID。 在同盟環境中，CloudAP 外掛程式會使用同盟提供者所傳回的 SAML 權杖，而不是使用者的認證。
F Microsoft Entra ID 會藉由與內嵌在 PRT 中的工作階段金鑰進行比較來驗證工作階段金鑰簽章，並驗證 nonce，以確認裝置在租用戶中是有效的，然後發出新的 PRT。 如先前所見，傳輸金鑰 (tkpub) 加密的會話金鑰再次附帶於 PRT。
G CloudAP 外掛程式會將加密的 PRT 和工作階段金鑰傳遞至 CloudAP。 CloudAP 會要求 TPM 使用傳輸金鑰 (tkpriv) 來解密會話金鑰，並使用 TPM 自己的金鑰來重新加密它。 CloudAP 會將加密的會話金鑰與 PRT 一同儲存在快取中。

注意

在外部啟用 usernamemixed 端點時，您可以在外部更新 PRT，而不需要 VPN 連線。

應用程式權杖要求期間的 PRT 使用方式

應用程式存取權杖請求期間的 PRT 使用情形

步驟 描述
A 應用程式，例如 Microsoft Outlook，會發起對 WAM 的令牌要求。 接著，WAM 會要求 Microsoft Entra WAM 外掛程式處理權杖要求。
B 如果應用程式的重新整理權杖已可供使用，Microsoft Entra WAM 外掛程式就會用其來要求存取權杖。 為了提供裝置繫結的證明，WAM 外掛程式會使用工作階段金鑰來簽署要求。 Microsoft Entra ID 會驗證工作階段金鑰，並發出應用程式的存取權杖和新的重新整理權杖，而且會由工作階段金鑰進行加密。 WAM 外掛程式請求 CloudAP 外掛程式解密令牌，CloudAP 外掛程式進一步請求 TPM 使用會話金鑰進行解密，最終使 WAM 外掛程式獲得兩個令牌。 接下來，WAM 外掛程式僅提供應用程式的存取權杖，同時使用 DPAPI 將重新整理權杖重新加密，並將其儲存在自己的快取中。
C 如果應用程式的刷新權杖不可用，Microsoft Entra WAM 外掛模組將使用 PRT 來請求存取權杖。 為了提供擁有權證明，WAM 外掛程式會使用會話密鑰來簽署包含 PRT 的要求。 Microsoft Entra ID 會藉由與內嵌在 PRT 中的工作階段金鑰進行比較來驗證工作階段金鑰簽章，並確認裝置有效，然後發出應用程式的存取權杖和重新整理權杖。 此外，Microsoft Entra ID 可以根據更新週期發出新的 PRT，並由工作階段密鑰加密這些 PRT。
D WAM 外掛程式請求 CloudAP 外掛程式解密權杖，CloudAP 隨後請求 TPM 使用會話金鑰解密，最終讓 WAM 外掛程式獲得這兩個權杖。 接下來，WAM 外掛程式僅提供應用程式的存取權杖，同時將重新整理權杖使用 DPAPI 重新加密，並將其儲存在自己的快取中。 WAM 外掛程式將在未來針對此應用程式使用重新整理權杖。 WAM 外掛程式也會將新的 PRT 往回提供給 CloudAP 外掛程式，其會先使用 Microsoft Entra ID 來驗證 PRT，然後在自己的快取中將其更新。 CloudAP 外掛程式之後會使用新的 PRT。
E WAM 會將新發出的存取權杖提供給 WAM，然後 WAM 再將其往回提供給呼叫應用程式

使用 PRT 的瀏覽器 SSO

使用 PRT 的瀏覽器 SSO

步驟 描述
A 使用者使用其認證登入 Windows 以取得 PRT。 一旦使用者開啟瀏覽器，瀏覽器 (或擴充功能) 就會從登錄載入 URL。
B 當使用者開啟 Microsoft Entra 登入 URL 時，瀏覽器或擴充功能就會以從登錄取得的 URL 來驗證 URL。 如果兩者相符，瀏覽器會叫用原生用戶端主機來取得令牌。
C 原生用戶端主機會驗證 URL 是否屬於 Microsoft 識別提供者 (Microsoft 帳戶或 Microsoft Entra ID)、解壓縮從 URL 傳送的 nonce，以及呼叫 CloudAP 外掛程式來取得 PRT Cookie。
D CloudAP 外掛程式會建立 PRT Cookie，並使用與 TPM 繫結的工作階段金鑰登入，然後將其傳回給原生用戶端主機。
E 原生用戶端主機會將此 PRT Cookie 傳回給瀏覽器，瀏覽器會將其作為 x-ms-RefreshTokenCredential 的要求標頭中的一部分，並從 Microsoft Entra ID 要求令牌。
F Microsoft Entra ID 會驗證 PRT cookie 上的工作階段金鑰簽章，驗證 nonce，確保裝置在租用戶中有效，然後為網頁發出識別碼權杖，並為瀏覽器發出加密的工作階段 cookie。

注意

上述步驟中所述的瀏覽器 SSO 流程不適用於私人模式中的工作階段，例如 Microsoft Edge 中的 InPrivate、Google Chrome 中的 Incognito (使用 Microsoft 帳戶延伸模組時) 或在 Mozilla Firefox v91+ 中的私人模式

下一步

如需針對 PRT 相關問題進行疑難排解的詳細資訊，請參閱針對 Microsoft Entra 混合式加入 Windows 10 或更新版本和 Windows Server 2016 裝置進行疑難排解。