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