今天推薦的是我一直以來都在關注的一個開源的OpenID Connect/OAuth 2.0服務框架——IdentityServer3。其支持完整的OpenID Connect/OAuth 2.0標準,使用它就能夠輕易地搭建一個單點登陸服務器。前端
說是一直關注,是由於1年前,要爲一個平臺搭建一個OAuth 2.0服務器,當時因爲IdentityServer3還處於開發階段,核心還不穩定,擴展功能也不完備。無奈只好熟讀OAuth 2.0的規範,並根據www.asp.net網站上的一個簡單示例本身實現了一個。不過如今好了,IdentityServer3在今年初正式發佈穩定的1.0版本。注:IdentityServer3的開發商以前就有IdentityServer2的產品,不過是IdentityServer3基於微軟最新的ASP.NET技術(好比OWIN等思想),以中間件的形式出現,更具擴展性。git
爲何會出現IdentityServer3這樣的框架呢?現代應用程序或多或少都是以下這樣的架構:github
在這種狀況下,前端、中間層和後端都須要進行驗證和受權來保護資源,因此不能僅僅在業務邏輯層或者服務接口層來實現基礎的安全功能。爲了解決這樣的問題,一般就會致使以下安全架構:後端
上圖實際上是把整個安全問題分解爲兩個方面:驗證和API訪問。安全
所謂驗證,就是應用程序須要知道當前用戶是誰。一般應用程序都會管理用戶信息,並表明用戶來訪問用戶被受權的資源。這對於典型的Web應用程序很常見,可是對於原生應用程序或基於JS的應用程序也是須要驗證。因此業界就制定了各類各樣的通用驗證協議:SAML2p、WS-Federation和OpenID Connect。SAML2p以前運用的比較普遍,不過做爲後起之秀的OpenID Connect(其本質是基於OAuth 2.0擴展而來)對現代的應用程序(尤爲移動應用)而言更加適合。服務器
對於API訪問。應用程序有兩種方式來和API進行通訊:使用應用程序本身的標識,或者表明用戶使用用戶的標識。OAuth2協議就容許應用程序先從安全令牌服務哪裏請求一個訪問令牌,而後隨後用這個令牌來和API進行通訊(API會訪問令牌服務器來驗證訪問者的令牌是否有效)。這就下降了客戶應用程序和API之間的複雜度,由於驗證和受權都被中心化了。架構
因爲OpenID Connect和OAuth 2.0很是相似,因此IdentityServer3的目標就是同時支持二者。其支持以下的標準:app
IdentityServer3做爲一個框架,具備不少擴展點(見官方文檔Service Factory章節),也附帶了不少擴展包:框架
最後想談談咱們是否應該把這樣的框架用於咱們產品(尤爲在比較關鍵的安全相關功能)中,也便是否應該「重複製造輪子」的問題。asp.net
在我看來,「咱們能夠重複創造本身的汽車,可是絕對不要重複製造輪子」。尤爲對於初創的小團隊更是如此,小團隊應該把精力用於快速驗證業務可行性上。首先,你沒法保證在製造輪子這件事情上比其餘人(好比IdentityServer3的開發者一直都是作驗證框架和服務器的)更專業;其次,你製造的輪子維護性確定比現成的輪子更難(除非你打算自造輪子的緣由就是有私心讓別人沒法接手),也比現成的輪子學習成本更難(團隊其餘成員沒法快速地基於現有文檔快速入手);最後,現成的輪子就算有欠缺,那麼正確的態度是參與開源項目來完善它促進社區發展,而不是因噎廢食。
「閱讀原文」是IdentityServer3的官方文檔目錄。能夠先通讀文檔後,來判斷是否用於本身的產品。