Oauth2介绍

Oauth2介绍

1. 简介

OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。
OAuth2.0是OAuth的第二代协议，也是目前普遍使用的协议。

简单来说，就是将用户登录认证逻辑集成起来，给其它应用使用，并为这些应用分配不同的权限。

关键词：第三方应用授权，短期(临时)授权

2. 场景

目前OAuth2.0协议/规范在市面上普遍被支持和使用。

1. 某些网站的第三方登录
   通过接入开放第三方登录的系统，例如QQ，微信等，可以信任新注册用户，并达到免密登录的效果。
   用户第一次使用第三方登录该网站，即为用户进行无感知的注册和登录，减少用户的操作步骤，同时可以确定该用户是可信的。

2. 微信小程序/公众号登录授权
   通过调用微信JS-API，用户点击授权之后，小程序可以获得用户的openid(该ID只在该小程序内有效)，昵称，头像等基本信息。

3. 架构

OAuth2.0 有四种授权方式，在流程上稍有简化和区别：

1. 授权码模式（authorization code）
   OAuth2.0 的标准模式，遵照协议的完全流程。

2. 简化模式（implicit）
   去除了授权码的流程，直接返回令牌。

3. 密码模式（resource owner password credentials）
   第三方【应用】直接通过用户密码从【应用】后台请求【认证中心】用户token，这需要认证中心对第三方应用完全信任。

4. 客户端模式（client credentials）
   【应用】自身向【认证中心】申请授权，请求资源，而与用户无关。

看图说话

4. 流程

角色：用户，应用，认证中心

4.1 OAuth2 平台开发流程

1. 数据库表设计
   除基本的通用表外，额外增加client表，记录第三方应用的APPID, APPKEY, APPSecret等信息。
   Oauth2.0搭建开放平台接口

2. 应用中心开发
   一般来说，OAuth会有一个针对开发者的应用管理平台，在平台上可进行应用的管理，创建删除，权限申请等。一般平台都称为：xx开放平台。
   

易班开放平台示例

3. 登录流程开发
   OAuth统一具有一个登陆中心，所有的第三方应用都从该页面进行用户认证。登陆时【认证中心】需要给用户提示，具体是登录到哪一个应用，需要授权什么权限。
   同时根据【应用】跳转过来URL附带的重定向地址(redirect_url)，在用户登录成功之后，会重定向到该地址，同时带上【认证中心】生成的code

可以看到，跳转过来的url上附带了应用ID(client_id)，授权类型(type), 应用地址(redirect_url)

4. 权限校验开发
   【认证中心】作为服务提供者，一般具有用户的一些基本信息。通过权限控制，控制【应用】访问【认证中心】接口时的权限，提供给【应用】固定范围内的用户信息。【应用】根据用户信息，生成自己的业务数据，存储在【应用】自己的空间内。也就是说，【认证中心】只提供给【应用】基本的用户信息。且不参与【应用的】业务数据流程。

4.2 应用开发接入流程

1. 申请应用接入
   应用开发人员在【认证中心】申请创建应用，获取到【认证中心】为应用生成的appKey和appSecret，通常来说，还可以同时申请【应用】访问【认证中心】时需要的权限。
   例如，可以获得用户的哪些信息

2. 开发登录认证逻辑
   根据登录接口获取的client_id和用户登录信息，【认证中心】负责完成用户的认证，并返回code给【认证中心】前端，前端再根据redirect_url跳转回第三方应用。

3. 根据令牌获取用户在平台的资源/数据/信息
   

【认证中心】登录页登陆成功，带上code回调到【应用】前端后，【应用】前端将code(授权码)传递给【应用】后端，该code与【应用】申请到的appsecret, appid, 【用户】有一对一的关系，且具有时效性，一般为10分钟，且一般只能消费一次，即便code泄露，没有appkey和appsecret，也无法获取到用户信息，而appkey和appsecret是存储在【应用】后端的，也没有泄露的可能性。
后端将code与appid,appsecret作为参数，加密，请求认证中心的接口进行消费，获取到用户的token，之后，就可以使用token获取用户数据，信息，资源。token一般具有固定的时效性，到期之后，需要用户再次授权。

5. 示例

用户架构基于OAuth + JWT + RBAC，也是目前普遍应用的一种模式，但在实际使用中，也要分场景来选择。
实际上，OAuth2并不适合使用在单个产品下，项目架构是单产品多服务的模式，各个服务之间的信息是互通的，与OAuth2的场景有违背，所以实际上对需求改造的过程中非常难受。
例如CMS和大屏应用是在同域下的，需要处理token存储冲突的问题，以及收到的需求是登陆时不跳转，且不能带参数，最终我们只能将登录页复制一份嵌入到大屏中以此去掉跳转和参数。

6. 联系

6.1 相关联系

1. JWT(Json Web Token)

2. RBAC(基于角色的权限校验)

3. 兼容多个第三方登录系统的数据库设计
   第三方账号登录的设计与数据库表的设计
   浅谈数据库用户表结构设计，第三方登录

6.2 相对联系

1. 如何判别某个系统是SSO还是OAuth2？

SSO(单点登录): 在多个应用系统中，只需要登录一次，就可以访问其他相互信任的应用系统。

OAuth2具有：
应用主体和授权中心主体
授权方式：域，参数，权限

OAuth2 在登陆时有权限信息展示，对于可选权限，【用户】可以自由选择授权权限给【应用】，URL中有重定向，APPID参数。权限有限。

SSO 无参数，同域，无权限信息，表明该系统可与用户中心无限制访问。

2. 何时有需要做OAuth平台的需求？
   1. 系统用户量基数大。
   2. 系统需要有限开放用户认证，信息，数据给其他独立的第三方系统。

7. 参考

7.1 支持OAuth2的常用平台

Github
OSChina
Baidu
Weibo
QQ
Weixin
LinkedIn

7.2 参考相关文档

文档介绍有限，请参考其他文档一起。

1. 阮一峰-理解OAuth 2.0

2. rfc6749

3. QQ-OAuth2 简介

4. 易班-授权概述