关于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站点获取接入站点凭证。
现在的问题是怎么将这两者结合一起成为一个系统?!
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 。实现免登录功能。