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/】 

以上逻辑未进行生产验证，仅一个思路，后期有时间，我会验证下。

 

 

 

------------------------------------- 补充 ： 楼下有哥们提出没有 B.com 什么事，确实是我疏忽了 ，现补充下（表示很尴尬。。）

A.com 与 B.com  因为涉及到跨站，因此给了A.com的Token B.com读不到(通常使用cookie 存Token)， 若权限确实容许 A.com 与 B.com 能够只认证一次，在A.com时己获取访问权限时，再转入B.com时，须要再次向 sso.com再次请求，但时sso.com在上次保留了 用户的登陆凭据，因此不须要用户再次输入账号及密码，直接下发B.com的 Token ，再跳转到B.com 。实现免登陆功能。