OAuth2.0 在 SSO中的應用~


關於OAuth2.0的介紹,請看下面鏈接(講的挺好的):

http://blog.csdn.net/seccloud/article/details/8192707

我的理解:

一共四個角色,A:Client(訪問者),B:資源擁有者,C:權限控制平台,D:資源中心

訪問流程:Client(訪問者)向 資源擁有者索要 資源訪問權限, 資源擁有者 給 Client(訪問者)開個授權書,Client(訪問者)拿着授權書到  權限控制平台 索要訪問令牌,Client(訪問者)獲取令牌,憑令牌訪問資源

打個不恰當比法:C 欠 A 一筆錢,A沒時間去向C 討債,於是A給B開個委托書讓B去拿錢,C 看了委托書確認了A確實委托了B,也確認了B的身份,於是C給了B一把保險櫃的鑰匙,讓B 自己去取錢。

以上兩個例子,相信你己了解什么是OAuth2.0了吧。

 

關於SSO 理解

去年看了博客園某大神的大作之后,記下了筆記沒留URL,現就對着筆記進行回顧下。

客人訪問A站點,需要登錄,於是跳轉到SSO進入登錄,backurl帶上A站點的URL,當登錄成功之后,跳回A站點,並給SSO的憑證與A站點的憑證。

客人從A站點跳轉到B站點,B站點需要驗證客人的身份,帶上SSO的憑證到SSO進入驗證,通過之后,給B站點發B站點的憑證。

一個邏輯:接入站點先判斷是否有SSO的憑證,有則判斷是否有接入站點憑證。若沒有SSO的憑證,有接入站點憑證需重新登錄。若有SSO的憑證,沒有接入站點憑證,從SSO站點獲取接入站點憑證。

 

現在的問題是怎么將這兩者結合一起成為一個系統?!

OK大片來了,以下將模擬騰訊開放平台中的QQ授權登錄(以下內容僅個人結合oauth2.0與sso業務邏輯想象出來,還未驗證)。   現有兩個子站點如A.com ,B.com ,還有個是統一登錄平台(sso.com)   首先接入站點需要從sso.com中獲取私鑰,指定一個notify頁面。1,客人client訪問A.com ,需要登錄A.com網站,跳轉到sso.com指定頁面(如:/login),帶上redirect_url就是a.com的URL。2,在這個登錄頁上輸入帳號及密碼登錄成功之后,sso.com 會向a.com  之前提交的nofity頁面回發用戶的票據及state(公鑰)。3,a.com  的notify頁面接受到票據與公鑰之后,將自己的私鑰與公鑰 按照簡單的算法處理下,再MD5之后,一起發回 sso.com,sso.com拿到a.com的身份信息之后確認正確,再將Token發給a.com。4,sso.com發送token之后,再跳轉回a.com的頁面(redirect_url)。     根據我的設想與實際操作騰訊單點登錄, 登錄成功之后,會有較長時間在那等待,就是在完成,發送票據、驗證client身份、下發token 的過程。     【轉載請標注,From http://www.cnblogs.com/jackicalSong/】  以上邏輯未進行生產驗證,僅一個思路,后期有時間,我會驗證下。      

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com