Microsoft Entra 已驗證的識別碼架構概觀
請務必規劃您的可驗認證解決方案，如此一來，除了簽發和 (或) 驗證認證之外，您對於解決方案的架構和商務影響可以有全盤的檢視。 如果您尚未檢閱這些內容，則建議您檢閱 Microsoft Entra 已驗證的識別碼簡介和常見問題集，然後完成使用者入門教學課程。
此架構概觀介紹 Microsoft Entra 已驗證的識別碼服務的功能和元件。 如需有關簽發和驗證的詳細資訊，請參閱
身分識別的方法
現今大部分的組織都會使用集中式身分識別系統來提供員工認證。 他們也會使用各種方法，將客戶、合作夥伴、廠商和信賴憑證者納入組織的信任界限。 這些方法包括同盟、使用 Microsoft Entra B2B 等系統建立和管理來賓帳戶，以及建立與信賴憑證者的明確信任。 大部分的商業關係都有數位成分，因此在組織之間啟用某種形式的信任需要付出大量努力。
集中式身分識別系統
集中式方法在許多情況下仍然可以順利運作，例如當應用程式、服務和裝置依賴網域或信任邊界內部使用的信任機制時。
在集中式身分識別系統中，身分識別提供者 (IDP) 控制認證的生命週期和用途。
然而，透過增強關鍵案例，在一些案例中使用分散式架構搭配可驗認證可以增加其價值，例如
保護員工和其他人身分識別的上線，包括在遠端的案例。
根據特定準則存取組織信任邊界內部資源。
存取信任邊界外部資源，例如使用組織所簽發的可攜式認證存取合作夥伴的資源。
分散式身分識別系統
在分散式身分識別系統中，認證的生命週期和用途由簽發者、持有者和取用認證的信賴憑證者共同控制。
請考慮圖表中的案例，其中的 Proseware (電子商務網站) 想要提供公司折扣給 Woodgrove 員工。
如果您不熟悉可驗認證 (VC，Verifiable Credentials)，您可能會對 VC 的術語感到困惑。 以下定義來自可驗認證資料模型 1.0 (英文) 的術語一節。 在每個定義後方，我們會將該定義關聯至上圖中的實體。
「行使簽發者角色的實體可以提出有關一或多個主體的宣告，從這些宣告建立可驗認證，然後將這些可驗認證傳輸給持有者。」
- 在上圖中，Woodgrove 對其員工而言，是可驗認證的簽發者。
「行使持有者角色的實體可以擁有一或多個可驗認證，並從這些認證產生展示檔。 持有者通常是 (但不一定是) 其所持有可驗認證的主體。 持有者會將其認證儲存在認證存放庫中。」
- 在上圖中，Alice 是 Woodgrove 員工。 從 Woodgrove 簽發者取得可驗認證，而且是該認證的持有者。
「行使驗證者角色的實體可以接收一或多個可驗認證 (可選擇內含在可驗展示檔中) 以進行處理。 其他規格可能會將此概念稱為信賴憑證者。」
- 在上圖中，Proseware 是 Woodgrove 所簽發認證的驗證者。
「認證是一或多個宣告的組合，由簽發者提出。 可驗認證是有著作者的防竄改認證，可以透過密碼編譯方式進行驗證。 可驗認證可以用來建立可驗展示檔，這也可以透過密碼編譯方式進行驗證。 認證中的宣告可以是與不同的主體相關。」
「分散式識別碼是可攜式 URI 識別碼，也稱為 DID，與實體相關聯。 這些識別碼通常用於可驗認證，且與主體、簽發者和驗證者相關聯。」
「分散式識別碼文件也稱為 DID 文件，是可以使用可驗資料登錄進行存取的文件，包含有特定分散式識別碼的相關資訊，例如相關聯的存放庫和公開金鑰資訊。」
在該案例中，簽發者和驗證者都有 DID 以及 DID 文件。 DID 文件包含有公開金鑰，以及與 DID 相關聯的 DNS Web 網域清單 (也稱為連結的定義域)。
Woodgrove (簽發者) 使用其私密金鑰簽署其員工的 VC；同樣地，Proseware (驗證者) 使其金鑰簽署出示 VC 的要求，該金鑰也與其 DID 相關聯。
「信任系統」是建立分散式系統之間信任的基礎。 其可以是分散式總帳，也可以是集中式項目，例如 DID Web。
「分散式總帳是用於記錄事件的非集中式系統。 這些系統為參與者建立足夠的信心，可以依賴其他人記錄的資料來做出營運決策。 這些系統通常會使用分散式資料庫，其中的不同節點會使用共識通訊協定，確認以密碼編譯方式簽署的交易順序。 經過一段時間後，數位簽署交易的連結通常會使得總帳的歷程記錄在實際上變成不可變。」
將集中式與分散式身分識別架構結合
當您檢查可驗認證解決方案時，最好先了解如何將分散式身分識別架構與集中式身分識別架構結合，以提供可降低風險並供應可觀營運效益的解決方案。
使用者旅程圖
此架構概觀依循求職者應徵並接受組織雇用成為員工的旅程。 接著依循員工和組織經歷各種變化，其間的可驗認證可以增強集中式流程。
這些使用案例中的執行者
Alice 是應徵並接受 Woodgrove, Inc. 雇用的人員。
Woodgrove, Inc. 是一家虛構公司。
Adatum 是 Woodgrove 的虛構身分識別驗證合作夥伴。
Proseware 是 Woodgrove 的虛構合作夥伴組織。
Woodgrove 同時使用集中式和分散式身分識別架構。
使用者旅程圖中的步驟
Alice 應徵、接受並入職 Woodgrove, Inc. 的職位。
存取 Woodgrove 信任邊界內部的數位資源。
存取 Woodgrove 信任邊界外部的數位資源，而不延伸 Woodgrove 或合作夥伴的信任邊界。
隨著商務持續營運，Woodgrove 必須持續管理身分識別。 本指南中的使用案例說明 Alice 如何使用自助功能取得和維護其識別碼，以及 Woodgrove 如何透過各種信任需求，新增、修改和結束企業對企業的關係。
這些使用案例示範如何結合集中式身分識別和分散式身分識別，以提供更健全且更有效率的身分識別及信任策略與生命週期。
使用者旅程圖：入職 Woodgrove
認知：Alice 想在 Woodgrove, Inc. 工作，因此造訪 Woodgrove 的求職網站。
啟動：Woodgrove 網站向 Alice 顯示可以證明其身分識別的方法，即透過 QR 代碼或深層連結提示她造訪信任的身分識別證明合作夥伴 Adatum。
要求並上傳：Adatum 向 Alice 要求身分識別的證明。 Alice 拍攝自己和駕照的相片，然後上傳至 Adatum。
簽發：Adatum 驗證 Alice 的身分識別後，Adatum 簽發可以證明其身分識別的可驗認證 (VC) 給 Alice。
展示檔：Alice (認證的持有人和主體) 接著可以存取 Woodgrove 求職入口網站以完成應徵流程。 當 Alice 使用 VC 存取入口網站時，Woodgrove 擔任驗證者和信賴憑證者的角色，信任來自 Adatum 的證明。
發放初始認證
Alice 接受 Woodgrove 雇用。 在入職流程中，會為 Alice 建立 Microsoft Entra 帳戶，讓她可以在 Woodgrove 信任邊界內部使用。 Alice 的主管必須想出如何讓在遠端工作的 Alice，以安全的方式接收初始登入資訊。 在過去，IT 部門可能早已將這些認證提供給主管，主管列印出這些認證，然後親手交給 Alice。 列印認證不適用於遠端員工。
VC 可以透過增強認證發放流程，增加集中式系統的價值。 Alice 可以使用其 VC 做為身分識別證明，接收其初始的使用者名稱和認證來存取集中式系統，而不需要主管提供認證。 Alice 出示在入職流程中加入錢包的身分識別證明。
在入職的使用案例中，信任關係的角色分散在簽發者、驗證者和持有者之間。
簽發者負責驗證宣告屬於其簽發的 VC。 Adatum 驗證 Alice 的身分識別而簽發 VC。 在此案例中，VC 的簽發不必考量到驗證者或信賴憑證者。
持有者擁有 VC 並起始 VC 的展示檔以進行驗證。 只有 Alice 可以出示其持有的 VC。
驗證者接受來自信任簽發者所簽發 VC 中的宣告，然後使用可驗認證資料模型中描述的分散式總帳功能驗證 VC。 Woodgrove 信任 Adatum 有關 Alice 身分識別的宣告。
透過將集中式和分散式身分識別架構結合以用於上線，Alice 進行身分識別驗證所需的專用資訊不必由 Woodgrove 存放，因為 Woodgrove 信任由其身分識別驗證合作夥伴 (Adatum) 簽發給 Alice 的 VC 可以確認她的身分。 將重複性工作降到最低，便可以程式設計方式且可預測的方法來實施初始的上線工作。
使用者旅程圖：存取信任邊界內部資源
身為員工，Alice 的運用範圍在 Woodgrove 的信任邊界內部。 Woodgrove 擔任身分識別提供者 (IDP)，對於 Alice 用來在 Woodgrove 信任邊界內部互動的身分識別及應用程式組態，Woodgrove 保有完整的控制權。 為使用 Microsoft Entra ID 信任邊界內部資源，Alice 可能提供多種形式的身分識別證明來登入 Woodgrove 的信任邊界，並且存取 Woodgrove 技術環境的內部資源。 多重證明是充分說明使用集中式身分識別架構的典型案例。
Woodgrove 管理信任邊界，而且使用良好的安全性做法，依據所執行的工作提供最低權限層級的存取權給 Alice。 為維持強大的安全性態勢，以及可能的合規性理由，Woodgrove 必須也要能夠追蹤員工的資源權限和存取權，以及必須能夠在終止雇用時撤銷權限。
Alice 只使用 Woodgrove 所維護的認證來存取 Woodgrove 資源。 Alice 不需要追蹤何時使用認證，因為 Woodgrove 正在管理認證，而且只會與 Woodgrove 資源搭配使用。 當需要存取 Woodgrove 資源時，身分識別只會在 Woodgrove 信任邊界內部有效，因此 Alice 不需要擁有認證。
在信任邊界內部使用 VC
個人員工有變更身分識別的需求，而 VC 可以增強集中式系統來管理這些變更。
Alice 受雇於 Woodgrove 後，可能會依據符合的特定需求而需要取得資源存取權。 例如，Alice 完成隱私權訓練後，可以簽發包含有該宣告的新員工 VC 給她，而且該 VC 可以用來存取受限資源。
VC 可以在信任邊界內部用來進行帳戶復原。 例如，如果員工遺失電話和電腦，員工可以從 Woodgrove 信任的身分識別驗證服務取得新 VC 以重新取得存取權，然後使用該 VC 取得新認證。
使用者旅程圖：存取外部資源
Woodgrove 與 Proseware 協商產品購買折扣。 所有 Woodgrove 員工皆有資格享有折扣。 Woodgrove 想要提供一個方法，讓 Alice 可以存取 Proseware 的網站，並且在購買產品時獲得折扣。 如果 Woodgrove 使用集中式身分識別架構，則有兩個方法可以提供折扣給 Alice：
Alice 可以提供個人資訊來向 Proseware 建立一個帳戶，然後 Proseware 必須驗證 Alice 受雇於 Woodgrove。
Woodgrove 可以延伸其信任邊界，將 Proseware 納入為信賴憑證者，然後 Alice 可以利用延伸的信任邊界來獲得折扣。
透過分散式識別碼，Woodgrove 可以提供可驗認證 (VC) 給 Alice，Alice 可以用來存取 Proseware 網站和其他外部資源。
藉由提供 VC 給 Alice，Woodgrove 證明 Alice 是員工。 Woodgrove 是 Proseware 驗證解決方案中信任的 VC 簽發者。 Woodgrove 簽發流程中的這份信任允許 Proseware 以電子方式接受 VC 為 Alice 是 Woodgrove 員工的證明，然後提供折扣給 Alice。 在驗證 Alice 所出示 VC 的期間，Proseware 會使用信任系統來檢查 VC 的有效性。 在此解決方案中：
Woodgrove 使 Alice 能夠提供雇用證明給 Proseware，而 Woodgrove 不必延伸其信任邊界。
Proseware 不需要延伸其信任邊界，就能驗證 Alice 是否為 Woodgrove 員工。 Proseware 可以改用 Woodgrove 提供的 VC。 因為未延伸信任界限，所以信任關係容易管理，而且 Proseware 可以透過不再接受 VC 的方式，輕鬆地結束關係。
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。
下一步
深入了解可驗認證的架構