入門教程:.NET開源OpenID Connect 和OAuth解決方案IdentityServer v3 介紹 (一)

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

典型的交互操做包括:前端

  • 瀏覽器與 web 應用程序進行通訊
  • Web 應用程序與 web Api (有時是在他們本身的有時表明用戶) 通訊
  • 基於瀏覽器的應用程序與 web Api 通訊
  • 本機應用程序與 web Api 通訊
  • 基於服務器的應用程序與 web Api 通訊
  • Web Api 和 web Api 交互(有時是在他們本身有時也表明用戶)

 

一般(前端,中間層和後端)的每一層有保護資源和執行身份驗證和受權的需求 —— 典型的狀況是針對同一用戶存儲。這就是爲何業務應用程序/端點自己不實現這些基本的安全功能的,寧願外包給安全令牌服務。這將有了下列安全體系結構:git

 

 

這對安全的需求分爲兩個部分。github

身份驗證web

當應用程序須要知道有關當前用戶的身份時,則需身份驗證。一般這些應用程序管理表明該用戶的數據,而且須要確保該用戶僅能夠訪問他容許的數據。最多見的例子是 (經典) 的 web 應用程序 —— 但本機和基於 JS 的應用程序,亦有須要進行身份驗證。後端

最多見的身份驗證協議是 SAML2p, WS-Federation 和 OpenID Connect —- SAML2p 是最受歡迎並被普遍部署的身份驗證協議。瀏覽器

OpenID Connect是三個中最新的一個,可是一般被認爲是將來的方向,由於它在現代應用程序中最具備潛力。它從一開始就是爲移動應用程序考慮的,被設計爲友好的 API。安全

API 訪問服務器

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

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

相關文章
相關標籤/搜索