最近做的一个项目是基于OAuth2.0协议的统一授权登录系统：
为什么要做这样一个项目？
- 原来的项目是通过提供sdk的方式，这样不同语言项目的接入都需要提供相应的sdk；
- 客户端版本升级需要通知各接入项目同步升级，费时费力；
- 安全问题：各项目可以接触到用户的密码等敏感信息。
这个项目解决了什么问题？
- 采用更为安全的OAuth2.0协议的第三方授权登录方式；
- 支持各种语言项目的接入；
- 作为公司内部系统登录的一个统一收口，同时满足单点登录的功能；
- 可防止CSRF攻击；
- 支持微信扫码登录。
系统框架设计图如下：
扩展点：
- 支持授权登录后直接跳转至用户指定的地址；
申请授权码的同时，发送的请求携带用户所要访问的指定地址的参数信息，在调用接入方回调地址的时候，再将改参数返回给接入方。
- 支持项目自定义登录背景；
通过开发接入方的自助管理平台，让接入方可以自行设置登录背景图片，在线编写样式和脚本，让项目实现自己个性化的登录背景。
- 支持同步退出；
用户退出之后，让发放给其登录过的所有系统的令牌失效，这样通过令牌就无法获取到用户信息，从而达到全部退出的效果；但实际情况下大多数系统接入方会缓存用户信息，而不会实时校验token的有效性，这个时候令牌虽然失效了，但接入的系统仍然可以正常使用；这个时候我们就通过在用户退出一个系统的时候，检测该用户授权登录过的其他系统，通过加载iframe的方式，把这些系统加载到退出页面，并隐藏这些iframe，然后在这些iframe中通过postMessage的方式发送消息给当前iframe页面，iframe页面通过addEventListener监听消息，收到退出的指令时，清除令牌及用户缓存信息。
OAuth简史：
云计算引出了大量的开放平台，各种第三方应用建立在开放平台之上，出于安全性的要求便出现了oauth协议，2007年发布了Oauth1.0协议， 2011年发布了2.0协议；
OAuth 2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。 OAuth 2.0关注客户端开发者的简易性，同时为Web应用，桌面应用，手机和起居室设备提供专门的认证流程。
OAuth1.0到2.0的演变
区别
OAuth1.0与OAuth2.0是相互不兼容的，因为提供了不同的授权方式：
2.0的用户授权过程有3步：
A)用户到授权服务器，请求授权，然后返回授权码(AuthorizationCode)
B)客户端由授权码到授权服务器换取访问令牌(access token)
C)用访问令牌去访问得到授权的资源
1.0的授权分4步：
A)客户端到授权服务器请求一个授权令牌(requesttoken&secret)
B)引导用户到授权服务器请求授权
C)用访问令牌到授权服务器换取访问令牌(accesstoken&secret)
D)用访问令牌去访问得到授权的资源
目前许多大型的互联网公司都在使用OAuth2.0协议进行开放授权服务：
Oauth2.0简介：
名词释义：
（1）Third-party application：第三方应用程序，也称为客户端，例如有道云笔记
（2）HTTP service：HTTP服务提供商，例如腾讯接口
（3）Resource Owner：资源所有者，也称为用户
（4）User Agent：用户代理，指浏览器
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器，它与认证服务器，可以是同一台服务器，也可以是不同的服务器
Oauth 2.0的运行流程：
客户端主要有四种授权模式：
客户端模式（Client Credentials Grant）：
用户直接向客户端注册，客户端以自己的名义要求服务提供商提供服务。
密码模式（Password Credentials Grant）：
用户必须把自己的密码给客户端，但是客户端不得储存密码，认证服务器只有在其他授权模式无法执行的情况下，才会考虑使用这种模式。
授权码模式（Authorization Code）：
功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与服务提供商的认证服务器进行互动。
简化模式（Implicit Grant Type）：
不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了“授权码”这个步骤
我们重点看一下授权码模式的授权流程：
A步骤中，客户端申请认证的URI，包含以下参数：
response_type： 表示授权类型，必选项，此处的值固定为"code"
client_id： 表示客户端的ID，必选项
redirect_uri： 表示重定向URI，可选项
scope： 表示申请的权限范围，可选项
state： 表示客户端的当前状态，一般可取UUID，认证服务器会返回该值校验
HTTP/1.1
GET:/authorize?response_type=code&scope=read&client_id=test&redirect_uri=http%3A%2F%2Fwww.server.com%3A8084%2Fclient%2Fauthorization_code_callback&state=fdfb847fddb94b3b899e998c040706a4
Host: www.server.com
B步骤中，用户授权/取消授权
C步骤中，服务器回应客户端的URI，包含以下参数：
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：如果客户端的请求中包含这个参数，认证服务器的响应也必须一模一样包含这个参数
HTTP/1.1
GET: /client?code=bb3281faac17bbd3ecac4b19165438c7&state=fdfb847fddb94b3b899e998c040706a4
Host: client
D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：
grant_type： 表示使用的授权模式，必选项，此处的值固定为"authorization_code"
code： 表示上一步获得的授权码，必选项
redirect_uri： 表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致
client_id： 表示客户端ID，必选项
HTTP/1.1 POST
Content-Type: application/x-www-form-urlencoded
Host: www.server.com
E步骤中，认证服务器发送的HTTP回复，包含以下参数：
access_token： 表示访问令牌，必选项
token_type： 表示令牌类型，必选项，可以是bearer类型或mac类型
expires_in： 表示过期时间，单位为秒，如果省略该参数，必须其他方式设置过期时间
refresh_token： 表示更新令牌，用来获取下一次的访问令牌，可选项
scope： 表示权限范围，如果与客户端申请的范围一致，此项可省略
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"59570f6f52d117282e1b4270b90adf0f",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"310e045c5d70cd5747f59f0accf25a51"
}
客户端系统接入流程：
参考链接：
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html