Microsoft Entra 驗證識別碼架構概觀
請務必規劃可驗證的認證解決方案，如此一來，除了發行或驗證認證之外，您還有解決方案架構和業務影響的完整檢視。 如果您尚未檢閱它們，建議您檢閱 Microsoft Entra 驗證識別碼 簡介和常見問題，然後完成用戶入門教學課程。
此架構概觀介紹 Microsoft Entra 驗證識別碼 服務的功能和元件。 如需發行和驗證的詳細資訊，請參閱
身分識別的方法
現今大部分的組織都會使用集中式身分識別系統來提供員工認證。 他們也會使用各種方法，將客戶、合作夥伴、廠商和信賴憑證者納入組織的信任界限。 這些方法包括同盟、使用 Microsoft Entra B2B 等系統建立和管理來賓帳戶，以及建立與信賴憑證者的明確信任。 大部分的商業關係都有數位成分，因此在組織之間啟用某種形式的信任需要付出大量努力。
集中式身分識別系統
在許多情況下，集中式方法仍然運作良好，例如當應用程式、服務和裝置依賴網域或信任界限內使用的信任機制時。
在集中式身分識別系統中，識別提供者 （IDP） 會控制認證的生命週期和使用方式。
不過，在某些情況下，使用具有可驗證認證的分散式架構可以藉由增強重要案例來提供價值，例如
保護員工和其他身分識別的上線，包括遠端案例。
根據特定準則存取組織信任界限內的資源。
使用組織發出的可攜式認證，存取信任界限以外的資源，例如存取合作夥伴的資源。
分散式身分識別系統
在分散式身分識別系統中，簽發者、持有者和取用認證的信賴憑證者之間會共用認證生命週期和使用方式。
請考慮 Proseware 是電子商務網站 Proseware 想要提供 Woodgrove 員工公司折扣的圖表案例。
如果您不熟悉 VCS，可驗證認證（VCS）的術語可能會造成混淆。 下列定義來自 可驗證認證數據模型 1.0 術語一節。 在每個之後，我們會將它們與上圖中的實體產生關聯。
「簽發 者 是實體可以執行的角色，其方式是判斷有關一或多個主體的宣告、從這些宣告建立可驗證的認證，以及將可驗證的認證傳送給持有人。
- 在上圖中，Woodgrove 是其員工可驗證認證的簽發者。
「持有者是實體可能執行的角色，方法是擁有一或多個可驗證的認證，並從中產生簡報。 持有人通常是，但不一定是他們持有的可驗證認證主體。 持有者將其認證儲存在認證存放庫中。
- 在上圖中，Alice 是 Woodgrove 員工。 他們從 Woodgrove 簽發者取得可驗證的認證，而且是該認證的持有者。
「驗證 器 是實體藉由接收一或多個可驗證認證來執行的角色，選擇性地在可驗證的簡報內進行處理。 其他規格可能會將此概念稱為信賴憑證者。」
- 在上圖中，Proseware 是 Woodgrove 所發出的認證驗證程式。
「認證是由簽發者所建立的一或多個宣告集合。 可驗證的認證是可竄改的認證，具有可密碼編譯驗證的撰寫權。 可驗證的認證可用來建置可驗證的簡報，也可以以密碼編譯方式驗證。 認證中的宣告可以與不同的主體有關。」
「分散式標識碼是與實體相關聯的可攜式 URI 型識別碼，也稱為 DID。 這些標識碼通常用於可驗證的認證，並與主體、簽發者和驗證者相關聯。
「分散式識別符檔，也稱為 DID 檔，是可使用可驗證的數據登錄存取的檔，並包含與特定分散式標識符相關的資訊，例如相關聯的存放庫和公鑰資訊。
在此案例中，簽發者和驗證者都有 DID 和 DID 檔。 DID 檔案包含公鑰，以及與 DID 相關聯的 DNS Web 網域清單（也稱為連結網域）。
Woodgrove （簽發者） 使用其私鑰簽署其員工 VCS：同樣地，Proseware（驗證者）簽署要求使用其密鑰來出示 VC，這也與其 DID 相關聯。
信任系統是建立分散式系統之間信任的基礎。 它可以是分散式總帳，也可以是集中式的，例如 DID Web。
「分散式總賬是記錄事件的非中心系統。 這些系統會建立足夠的信心，讓參與者依賴其他人記錄的數據來進行作業決策。 它們通常會使用分散式資料庫，其中不同的節點會使用共識通訊協定來確認密碼編譯簽署交易的順序。 隨著時間，數字簽署交易的連結往往使總賬的歷程記錄實際上不可變。
結合集中式和分散式身分識別架構
當您檢查可驗證的認證解決方案時，了解分散式身分識別架構如何與集中式身分識別架構結合，以提供可降低風險並提供重大作業優勢的解決方案很有説明。
使用者旅程圖
此架構概觀遵循候選人和員工的旅程，該員工會申請並接受與組織雇用。 然後，它會透過可驗證認證可增強集中式程式的變更來追蹤員工和組織。
這些使用案例中的動作專案
Alice，一個申請和接受伍德格羅夫公司就業的人。
Woodgrove， Inc， 一家虛構的公司。
Adatum，Woodgrove 的虛構身分識別驗證合作夥伴。
Proseware，Woodgrove 虛構的合作夥伴組織。
Woodgrove 同時使用集中式和分散式身分識別架構。
使用者旅程圖中的步驟
Alice 申請、接受及上線至 Woodgrove， Inc. 的位置。
存取 Woodgrove 信任界限內的數字資源。
在 Woodgrove 信任界限之外存取數位資源，而不需要延伸 Woodgrove 或合作夥伴的信任界限。
當 Woodgrove 繼續經營其業務時，它必須持續管理身分識別。 本指南中的使用案例說明 Alice 如何使用自助功能來取得和維護其標識碼，以及 Woodgrove 如何新增、修改和結束具有不同信任需求的企業對企業關係。
這些使用案例示範如何結合集中式身分識別和分散式身分識別，以提供更健全且更有效率的身分識別和信任策略和生命週期。
使用者旅程圖：上線至 Woodgrove
認識：Alice 有興趣為 Woodgrove 公司工作，並流覽 Woodgrove 的職業網站。
啟用：Woodgrove 網站向 Alice 提供一種方法來證明其身分識別，方法是提示他們使用 QR 代碼或深層連結來流覽其受信任的身分證明合作夥伴 Adatum。
要求和上傳：Adatum 會向Alice要求身分識別證明。 Alice 拍攝自拍和駕駛執照圖片，並將其上傳至 Adatum。
發行：一旦 Adatum 驗證 Alice 的身分識別，Adatum 就會發出 Alice 可驗證的認證 （VC） 來證明其身分識別。
簡報：Alice（認證持有者和主體）可以接著存取 Woodgrove 職業入口網站來完成應用程式程式。 當Alice使用 VC 存取入口網站時，Woodgrove 會擔任驗證者和信賴憑證者的角色，信任 Adatum 的證明。
散發初始認證
Alice 接受 Woodgrove 的雇用。 在上架程式中，會建立 Microsoft Entra 帳戶，讓 Alice 在 Woodgrove 信任界限內使用。 Alice 的經理必須瞭解如何讓遠端工作的 Alice 以安全的方式接收初始登入資訊。 過去，IT 部門可能已將這些認證提供給其經理，他們會列印認證並將其交給 Alice。 列印認證不適用於遠端員工。
VCS 可以藉由增強認證散發程式，將價值新增至集中式系統。 Alice 不需要管理員提供認證，而是可以使用其 VC 作為身分識別證明，以接收其初始使用者名稱和認證以進行集中式系統存取。 Alice 將身分證明呈現在上線程式期間新增至錢包的身分識別證明。
在上線使用案例中，信任關係角色會在簽發者、驗證程式和持有者之間散發。
簽發者負責驗證屬於其發行之 VC 一部分的宣告。 Adatum 會驗證 Alice 的身分識別以發出 VC。 在此情況下，不會考慮驗證者或信賴憑證者，就會發出 VCS。
持有人擁有 VC，並起始 VC 的呈現以進行驗證。 只有 Alice 可以呈現她持有的 VCS。
驗證器會接受其信任之簽發者在 VC 中的宣告，並使用可驗證認證數據模型中所述的分散式總帳功能來驗證 VC。 Woodgrove 信任 Adatum 關於 Alice 身分識別的主張。
藉由結合用於上線的集中式和分散式身分識別架構，將身分識別驗證所需的Alice特殊許可權資訊，例如政府標識碼，不需要由 Woodgrove 儲存，因為它們相信Alice的 VC 是由身分識別驗證合作夥伴 （Adatum） 所簽發的 VC 會確認其身分識別。 重複的工作會最小化，而且可以實作初始上線工作的程序設計與可預測方法。
使用者旅程圖：存取信任界限內的資源
作為員工，Alice 正在 Woodgrove 的信任界限內運作。 Woodgrove 可做為識別提供者 （IDP），並維持對身分識別的完整控制，以及 Alice 用來在 Woodgrove 信任界限內互動的應用程式設定。 為了在 Microsoft Entra ID 信任界限中使用資源，Alice 提供可能多種形式的識別證明，以登入 Woodgrove 的信任界限，並存取 Woodgrove 技術環境內的資源。 多重證明是使用集中式身分識別架構提供良好服務的一般案例。
Woodgrove 會管理信任界限，並使用良好的安全性做法，根據所執行的工作，為 Alice 提供最低許可權的存取層級。 為了維持強大的安全性態勢，並可能基於合規性考慮，Woodgrove 也必須能夠追蹤員工的許可權和資源存取權，而且必須在終止僱用時撤銷許可權。
Alice 只會使用 Woodgrove 維護的認證來存取 Woodgrove 資源。 Alice 不需要追蹤何時使用認證，因為 Woodgrove 正在管理認證，而且只會與 Woodgrove 資源搭配使用。 身分識別只有在需要存取 Woodgrove 資源時，才能在 Woodgrove 信任界限內有效，因此 Alice 不需要擁有認證。
在信任界限內使用 VM
個別員工有不斷變化的身分識別需求，而 VCS 可以增強集中式系統來管理這些變更。
當 Woodgrove Alice 採用時，可能需要根據符合特定需求來存取資源。 例如，當 Alice 完成隱私權訓練時，她可以使用該宣告來發行新的員工 VC，而且該 VC 可用來存取受限制的資源。
VCS 可用於帳戶復原的信任界限內。 例如，如果員工遺失了手機和計算機，他們可以從 Woodgrove 信任的新 VC，然後使用該 VC 取得新的認證來重新取得存取權。
使用者旅程圖：存取外部資源
Woodgrove 與 Proseware 談判產品購買折扣。 所有 Woodgrove 員工都有資格享受折扣。 Woodgrove 希望提供 Alice 一種方式來存取 Proseware 的網站，並收到購買的產品折扣。 如果 Woodgrove 使用集中式身分識別架構，有兩種方法可提供 Alice 折扣：
Alice 可以提供個人資訊來建立具有 Proseware 的帳戶，然後 Proseware 必須驗證 Alice 與 Woodgrove 的雇用。
Woodgrove 可以擴大其信任界限，將 Proseware 納入為信賴憑證者，Alice 可以使用延伸的信任界限來接收折扣。
使用分散式標識碼，Woodgrove 可以提供 Alice 可驗證的認證 （VC），讓 Alice 可用來存取 Proseware 的網站和其他外部資源。
藉由提供 Alice VC，Woodgrove 會證明 Alice 是員工。 Woodgrove 是 Proseware 驗證解決方案中受信任的 VC 簽發者。 這種對 Woodgrove 發行程式的信任可讓 Proseware 以電子方式接受 VC，證明 Alice 是 Woodgrove 員工，並提供 Alice 折扣。 在驗證 VC Alice 時，Proseware 會使用信任系統來檢查 VC 的有效性。 在此解決方案中：
Woodgrove 可讓 Alice 提供就業證明，而 Woodgrove 不必延長其信任界限。
Proseware 不需要擴充其信任界限，以驗證 Alice 是 Woodgrove 的員工。 Proseware 可以改用 Woodgrove 提供的 VC。 由於信任界限並未擴大，因此管理信任關係會比較容易，而 Proseware 可藉由不再接受 CS 來輕鬆結束關聯性。
Alice 不需要提供 Proseware 個人資訊，例如電子郵件。 Alice 會在個人裝置上的錢包應用程式中維護 VC。 唯一可以使用 VC 的人員是 Alice，而且 Alice 必須起始認證的使用方式。 VC 的每個使用量都會由錢包應用程式記錄，因此 Alice 有使用 VC 的時機和位置記錄。
藉由結合在 Woodgrove 的信任界限內外運作的集中式和分散式身分識別架構，可降低複雜度和風險，並讓關聯性變得更容易管理。
一段時間的變更
Woodgrove 會新增和結束與其他組織的目前商務關係，而且需要判斷何時使用集中式和分散式身分識別架構。
藉由結合集中式和分散式身分識別架構，與身分識別和身分識別證明相關聯的責任和努力會分散，風險會降低。 使用者不會風險經常或發佈其私人資訊給許多未知的驗證者。 具體而言：
- 在集中式身分識別架構中，IDP 會發出認證，並執行這些核發認證的驗證。 IDP 會處理所有身分識別的相關信息。 它會將它們儲存在目錄中，或從目錄中擷取它們。 或者，IDP 可以接受來自其他 IDP 系統的安全性令牌，例如社交登入或商務夥伴。 若要讓信賴憑證者在IDP信任界限中使用身分識別，必須將它們設定為接受IDP所簽發的令牌。
分散式身分識別系統的運作方式
在分散式身分識別架構中，簽發者、使用者和信賴憑證者 (RP) 各自在建立和確保彼此認證的持續可信任交換方面扮演了某種角色。 執行者 DID 的公開金鑰可透過信任系統解析，其允許簽章驗證，因此信任任何成品，包括可驗認證。 信賴憑證者可以取用可驗認證，而不需與簽發者建立信任關係。 相反地，簽發者會向主體提供認證，作為出示給信賴憑證者的證明。 執行者之間的所有訊息都會使用執行者的 DID 來簽署；來自簽發者和驗證者的 DID 也需要擁有產生要求的 DNS 網域。
例如：當 VC 持有者需要存取資源時，他們必須將 VC 出示給該信賴憑證者。 他們的做法是使用電子錢包應用程式來讀取 RP 出示 VC 的要求。 在讀取要求時，電子錢包應用程式會使用 RP 的 DID 來尋找使用信任系統的 RP 公開金鑰，並驗證出示 VC 的要求未曾遭到竄改。 為了證明網域擁有權，電子錢包也會檢查 RP DNS 網域中裝載的中繼資料文件中是否參考了 DID。
流程 1：可驗認證發行
在此流程中，認證持有者會與簽發者進行互動以要求可驗認證，如下圖所示
持有人會使用瀏覽器或原生應用程式來存取簽發者的 Web 前端以開始流程。 在該處，簽發者網站會驅動使用者收集數據，並執行簽發者特定的邏輯，以判斷是否可以發出認證及其內容。
簽發者 Web 前端會呼叫 Microsoft Entra 驗證識別碼服務，以產生 VC 簽發要求。
Web 前端會將要求的連結轉譯為 QR 代碼或裝置特定的深層連結 (視裝置而定)。
持有人會使用 Microsoft Authenticator 等電子錢包應用程式掃描步驟 3 中的 QR 代碼或深層連結
電子錢包會從該連結下載要求。 要求包括：
簽發者的 DID。 簽發者的 DID 會由電子錢包應用程式用於透過信任系統解析，以尋找公開金鑰和連結網域。
具有 VC 資訊清單的 URL，其會指定簽發 VC 的合約需求。 合約需求可以包含 id_token、必須提供的自我證明屬性，或出示另一個 VC。
VC 的外觀和風格 (標誌檔案的 URL、色彩等)。
錢包會驗證發行要求，並處理合約需求：
驗證簽發要求訊息是否由透過信任系統解析的 DID 文件中找到的簽發者金鑰所簽署。 驗證簽章可確保訊息未曾遭到竄改。
驗證簽發者是否擁有簽發者 DID 文件中參考的 DNS 網域。
根據 VC 合約需求，電子錢包可能會要求持有者收集其他資訊，例如要求自我簽發的屬性，或瀏覽 OIDC 流程以取得 id_token。
將合約所需的成品提交至 Microsoft Entra 驗證識別碼服務。 Microsoft Entra 驗證識別碼服務會傳回 VC，並以簽發者的 DID 金鑰簽署，且電子錢包會安全地儲存 VC。
如需如何建置發行解決方案和架構考慮的詳細資訊，請參閱規劃您的 Microsoft Entra 驗證識別碼 發行解決方案。
流程 2：可驗認證出示
在此流程中，持有人會與信賴憑證者 (RP) 進行互動，以在其授權需求中出示 VC。
持有人會使用瀏覽器或原生應用程式來存取信賴憑證者的 Web 前端以開始流程。
Web 前端會呼叫 Microsoft Entra 驗證識別碼服務，以產生 VC 出示要求。
Web 前端會將要求的連結轉譯為 QR 代碼或裝置特定的深層連結 (視裝置而定)。
持有人會使用 Microsoft Authenticator 等電子錢包應用程式掃描步驟 3 中的 QR 代碼或深層連結
電子錢包會從該連結下載要求。 要求包括：
RP 的 DID，錢包在信任系統中查閱。
電子錢包會驗證出示要求，並尋找滿足該要求的預存 VC。 根據必要的 VC，電子錢包會引導主體選取並同意使用 VC。
- 主體同意與 RP 共用 VC
然後，電子錢包會將出示回應承載傳送給主體所簽署的 Microsoft Entra 驗證識別碼服務。 其包含：
主體同意的 VC。
主題 DID。
RP DID 作為承載的「物件」。
Microsoft Entra 驗證識別碼服務會驗證電子錢包所傳送的回應。 在某些情況下，VC 簽發者可以撤銷 VC。 若要確定 VC 仍然有效，驗證者必須和 VC 簽發者確認。 這會依據驗證者在步驟 2 中要求 VC 的方式而定。
驗證之後，Microsoft Entra 驗證識別碼服務會以結果回呼 RP。
如需如何建置驗證解決方案和架構考慮的詳細資訊，請參閱規劃您的 Microsoft Entra 驗證識別碼 驗證解決方案。
重要心得
分散式架構可用於增強現有的解決方案並提供新功能。
若要達成分散式身分識別基礎 （DIF） 和 W3C 設計目標的願望，建立可驗證的認證解決方案時，應考慮下列專案：
系統中的執行者之間沒有信任建立的中心點。 也就是說，信任界限不會透過同盟擴充，因為執行者信任特定的 VM。
- 信任系統可讓您探索任何執行者的分散式識別碼 (DID)。
解決方案可讓驗證者驗證來自任何簽發者的任何可驗認證 (VC)。
解決方案不會讓簽發者控制主體或驗證者 (信賴憑證者) 的授權。
執行者會以低耦合的方式運作，每個執行者都能夠完成其角色的工作。
簽發者對每個 VC 要求都一視同仁，而不會對所服務的要求有不同的處理方式。
一旦簽發，主體即擁有自己的 VC，並且可以向任何驗證者出示其 VC。
驗證者可以驗證來自任何主體或簽發者的任何 VC。
下一步
深入瞭解可驗證認證的架構