最近在對基於token作身份認證的項目中擴展sso。git
項目大體架構以下 github
其中服務器端是RESTful風格的API服務器,客戶端基於Vue開發的SPA。身份認證是基於token,客戶端登陸以後,服務器端驗證併發送JWT token給客戶端,客戶端將token存入localStorage中並每次恢復到Vuex中,客戶端每次請求都會在HTTP自定義頭部中附帶token。安全
本文簡述下我對OIDC解決方案的簡單理解以及基於上述架構實現sso的思路。服務器
OIDC的官方解釋以下cookie
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.session
也就是OAuth2.0只解決了資源的訪問和分享,OIDC則基於此實現了用戶的認證。它的主要目的是提供一次登陸,多個站點享有登陸狀態。也就是當用戶在某一使用OIDC的網站登陸時,用戶被重定向到OpenID站點登陸,而後重定向回原來網站。架構
OIDC已經有不少的企業在使用,好比Google的帳號認證受權體系,Microsoft的帳號體系也部署了OIDC,固然這些企業有的也是OIDC背後的推進者。併發
OAuth2提供了Access Token來解決受權第三方客戶端訪問受保護資源的問題;類似的,OIDC在這個基礎上提供了ID Token來解決第三方客戶端標識用戶身份認證的問題。OIDC的核心在於在OAuth2的受權流程中,一併提供用戶的身份認證信息(ID-Token)給到第三方客戶端,ID-Token使用JWT格式來包裝,得益於JWT(JSON Web Token)的自包含性,緊湊性以及防篡改機制,使得ID-Token能夠安全的傳遞給第三方客戶端程序而且容易被驗證。應用服務器,在驗證ID-Token正確以後,使用Access-Token向接口換取用戶的更多的信息。ide
第一期先從簡,也不討論什麼OIDC協議族,就單單說一下OIDC是怎麼運做的。以仍是以午安網舉例。網站
若是我要使用大午安帳號登入午安空間網站,那麼這個大體流程以下:
使用Implicit Flow設計可能比較粗糙或者有問題,若是有問題但願評論一下幫我修正修正。 設計使用的是Implicit Flow。
沒啥好說的,客戶端清理本身的狀態,而後發出登出請求給oidc-server。
這塊就找到了一個網上的例子
其利用oipc協議族裏的Discovery服務中提供的一個check_session_iframe接口。
核心原理是讓客戶端插入一個oidc-server頁面的iframe並週期性的檢查,當我在「午安空間」點擊登出的時候,會發出登出請求給oidc-server並觸發oidc-server的站點清理本身的cookie,而後在以前客戶端中使用check_session_iframe這個隱藏的iframe能夠檢測到這種變化,從而使得客戶端能夠得知用戶已在再其餘的應用的客戶端退出登陸,這時候就清理本身客戶端的登陸狀態。
例子中的客戶端代碼
這部分放的是下版本要加的或者完善的。
瞭解下Authorization Code Flow。
若是隻有上面的解決方案的話會存在一個問題,那就是若是我sso已登陸,我到另外一個網站好比午安影視,我須要點擊登入以後纔會出現登陸狀態。也就是說沒有自動登陸。
一個實現的方法是能夠在一開始就去訪問oidc-server詢問是否已經登陸,oidc-server的協議族Discovery提供一個接口。