oauth2.0 sso jackical
關於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/】 以上邏輯未進行生產驗證，僅一個思路，後期有時間，我會驗證下。
