入門教程：.NET開源OpenID Connect 和OAuth解決方案IdentityServer v3 介紹 （一）

現代的應用程序看起來像這樣:

典型的交互操做包括：

• 瀏覽器與 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 驗證服務器。