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/】 
以上逻辑未进行生产验证,仅一个思路,后期有时间,我会验证下。
 
 
 

你可能感兴趣的:(OAuth2.0 在 SSO中的应用~)