.NET開源OpenID和OAuth解決方案Thinktecture 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進行溝通。有時這兩種方法必須相結合。

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

 

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

客戶端

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

默認狀況下，客戶端能夠請求在 IdentityServer-中定義的任何做用域，但您能夠限制每一個客戶端能夠請求的做用域。

做用域

做用域是一個資源 （一般也稱爲 Web API） 的標識符。你能夠如範圍被稱爲"日曆"爲您建立日曆 API — — 或"calendar.readonly"若是你想要將您的日曆的 API 分割成子"地區"-在這種狀況下只讀訪問權限。

若是容許，此做用域將會包括做爲訪問令牌中的索賠與客戶端而後能夠請求如"日曆"範圍-的標記。而後能夠肯定範圍是目前驗證的訪問令牌時日曆 API （或資源）。

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

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

IdentityServer 既支持"資源"的做用域，也支持 OpenID 鏈接做用域。

 

理解OAuth 2.0

Thinktecture IdentityServer and CodeFluent Entities

基於Token的認證和基於聲明的標識

Thinktecture Identity Server 3

Identity Server 3 Standalone Implementation Part 1

Identity Server 3 Standalone Implementation Part 2

Identity Server 3 Standalone Implementation Part 3