OAuth2.0 在 SSO中的应用~

Posted 2020-07-02

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

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