如何進行IdentityServer的安全模型分析

本篇文章為大家展示了如何進行IdentityServer的安全模型分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

典型的交互操作包括：

• 瀏覽器與 web 應用程序進行通信

• Web 應用程序與 web Api （有時是在他們自己的有時代表用戶） 通信

• 基于瀏覽器的應用程序與 web Api 通信

• 本機應用程序與 web Api 通信

• 基于服務器的應用程序與 web Api 通信

• Web Api 和 web Api 交互（有時是在他們自己有時也代表用戶）

通常（前端，中間層和后端）的每一層有保護資源和執行身份驗證和授權的需求 —— 典型的情況是針對同一用戶存儲。這就是為什么業務應用程序/端點本身不實現這些基本的安全功能的，寧愿外包給安全令牌服務。

身份驗證

當應用程序需要知道有關當前用戶的身份時，則需身份驗證。通常這些應用程序管理代表該用戶的數據，并且需要確保該用戶僅可以訪問他允許的數據。最常見的例子是 （經典） 的 web 應用程序 —— 但本機和基于 JS 的應用程序，亦有需要進行身份驗證。

最常見的身份驗證協議是 SAML2p, WS-Federation 和 OpenID Connect —- SAML2p 是最受歡迎并被廣泛部署的身份驗證協議。

OpenID Connect是三個中最新的一個，但是通常被認為是未來的方向，因為它在現代應用程序中最具有潛力。它從一開始就是為移動應用程序考慮的，被設計為友好的 API。

API 訪問

應用程序有兩種基本方式 —— 使用應用程序的標識，或委派用戶的身份與API進行溝通。有時這兩種方法必須相結合。

OAuth3 是允許應用程序從安全令牌服務請求訪問令牌并使用它們與Api通信的一個協議。它減少了客戶端應用程序，以及 Api 的復雜性，因為可以進行集中身份驗證和授權。OpenID解決跨站點的認證問題，OAuth解決跨站點的授權問題。認證和授權是密不可分的。而OpenID和OAuth這兩套協議出自兩個不同的組織，協議上有相似和重合的之處，所以想將二者整合有些難度。好在OpenID Connect作為OpenID的下一版本，在OAuth 2.0的協議基礎上進行擴展，很好的解決了認證和授權的統一，給開發者帶來的便利。Thinktecture IdentityServer v3 是一個.NET 平臺上開源的OpenID Connect 提供者 和 OAuth3 驗證服務器。

IdentityServer 的安全模型基于兩個基本原語： 客戶端和作用域

客戶端

客戶端是請求訪問IdentityServer或身份令牌的軟件。客戶可以是不同類型的應用：桌面或移動的，基于瀏覽器的或基于服務器的應用。OpenID 連接和 OAuth3 描述 （也稱為流程）不同客戶端如何請求令牌模式。檢查的規格為有關流程的詳細信息。

默認情況下，客戶端可以請求在 IdentityServer-中定義的任何作用域，但您可以限制每個客戶端可以請求的作用域。

作用域

作用域是一個資源 （通常也稱為 Web API） 的標識符。你可以如范圍被稱為"日歷"為您創建日歷 API — — 或"calendar.readonly"如果你想要將您的日歷的 API 分割成子"地區"-在這種情況下只讀訪問權限。

如果允許，此作用域將會包括作為訪問令牌中的索賠與客戶端然后可以請求如"日歷"范圍-的標記。然后可以確定范圍是目前驗證的訪問令牌時日歷 API （或資源）。

根據流程和配置，請求作用域將顯示給用戶之前頒發的令牌。這使用戶有機會來允許或拒絕訪問該服務。這就被所謂的同意。

OpenID 連接的作用域有點特殊。它們定義一個可以要求用戶的身份信息和用戶信息終結點。每一個 OpenID 連接作用域有關聯的聲明，如"Profile" 作用域映射到的名字、 姓氏、 性別、 個人資料圖片和更多。

IdentityServer 既支持"資源"的作用域，也支持 OpenID 連接作用域。

上述內容就是如何進行IdentityServer的安全模型分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。