爱测未来开发-基于Oauth2.0的单点登录系统
一、Oauth2.0 介绍
OAuth2.0是2006年开始设计OAuth协议的下一个版本，OAuth2.0同时提供Web，桌面和移动应用程序的支持，并较1.0相比整个授权验证流程更简单更安全。目前国内百度开发平台、腾讯开放平台、新浪微博开发平台的认证都是使用该协议。
Oauth2.0协议相当于在第三方应用程序与用户资源提供商之间，设置了一个授权层（authorization server）。第三方应用不能直接登录用户资源提供商，只能登录到授权层，以此将用户的信息和资源与第三方应用分割开来。用户授权第三方应用以后，第三方应用拿到资源令牌，相当于有了用户获取资源的权限。但是却没有用户的用户名与密码，用户可以在登录的时候，指定资源令牌的权限范围和有效期。
二、单点登录用场景
对于研发和测试人员来说、平时经常需要登录公司或者部门内部的各个平台进行相关的工作，比如:持续集成、工单系统、RMD（项目管理系统）等等。如果挨个平台输入用户名与密码进行登录，是非常繁琐的同时又有很大的安全隐患。为了解决这个问题，我们可以搭建统一的认证授权平台。这样只要用户登录了授权平台就可以免登陆进入授权平台接入的各个子系统。
所以单点登录解决了多系统中间切换的以下问题：
A、免登陆跳转、解决了流程繁琐的问题。
B、无需在各个平台中暴露用户名、密码，解决了安全的问题。
C、用户没法控制各个平台获取的用户信息的范围与时限的问题。
而Oauth2.0协议就能很好的解决这样的一些问题。
三、Oauth2.0单点登录流程
第一步: 搭建基于Oauth2.0的认证授权服务器。实现功能（Oauth2.0协议接口、资源服务器访问、应用授权、令牌管理）。
第二步: 第三方应用向授权中心申请接入。授权中心会赋予第三方应用client_id与secret_key。
第三步: 用户进入第三方应用，第三方应用要求用户给予用户资料访问的授权。此时会302跳转到认证授权服务器登录页面。其中授权的模式有以下几种，推荐使用authorization code模式。
A、authorization code：授权码模式，是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。授权的令牌与应用接入key对于普通用户来说是隔离的。
B、Implicit：简化模式，直接在浏览器中向认证服务器申请令牌，url中会直接暴露用户的AccessToken。
B、密码模式（resource owner password credentials）：用户向第三方应用提供自己的用户名和密码。第三方应用使用这些信息，向"服务商提供商"索要授权。
C、客户端模式（client credentials）：用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
演示：
调用认证接口：http://localhost:8080/authorize
发送参数：
| 名称 |
含义 |
备注 |
| client_id |
接入客户端的id |
client_id 向认证中心申请 |
| response_type |
返回响应的类型 |
|
| redirect_uri |
重定向的回调地址 |
|
例如：
http://localhost:8080/authorize?client_id=3c65d9602a6a44daaa80e3609c4a2be6&response_type=code&redirect_uri=http://www.baidu.com
第四步: 用户同意给予第三方应用应用用户资料的授权，此时从认证服务器302跳转回以前的第三方应用，同时附带上授权码。第三方应用得到了认证服务器的授权码。
例如：https://www.baidu.com/?code=c54c47eb7275e5e1fab2cf7ce7d0c4eb
第五步: 第三方应用根据授权码与自身的secret_key向认证服务器申请资源令牌。此处是在后台进行的，用户是不可见的。
演示：通过授权码换取access_token资源令牌，调用接口http://localhost:8080/accessToken
通过POST方式发送参数
| 名称 |
含义 |
备注 |
| client_id |
接入客户端的id |
client_id 向认证中心申请 |
| client_secret |
接入客户端的key |
key 向认证中心申请 |
| redirect_uri |
重定向的回调地址 |
|
| grant_type |
授权类型 |
固定为：authorization_code |
| code |
授权码 |
|
返回内容：{"access_token":"409ace4f7308fbd3e236addef0e0f1dd","expires_in":3600}
第六步: 认证服务器对第三方应用进行认证，确认所有信息正确以后向第三方应用发放资源令牌。此处是在后台进行的，用户是不可见的。
演示：
http://localhost:8080/v1/openapi/userInfo?access_token=409ace4f7308fbd3e236addef0e0f1dd
返回结果：
Base64编码后的返回结果：
eyJ3aGVuQ3JlYXRlZCI6IjIwMTUwMzEzMDU1NjAwLjBaIiwibWFpbCI6InRlc3RAaWZseXRlay5jb20iLCJkaXNwbGF5TmFtZSI6Iua1i+ivlei0puWPtyIsImRlc2NyaXB0aW9uIjoi5rWL6K+V6LSm5Y+3In0=
第七步: 第三方应用根据资源令牌从服务器获取用户的信息（信息中是不包含类似密码这样的敏感信息的）。此处是在后台进行的，用户是不可见的。
四、联系我们
以上是我在进行基于Oauth2.0的SSO开发过程中的一些体会，后续也会在这方面进行一些深入的研究学习，有相关兴趣爱好的同学可以关注我们的公共号，持续交流。
公众号：itest_forever
CSDN:http://blog.csdn.net/itest_2016
QQ群：274166295（爱测未来2群）、610934609（爱测未来3群）