1.什么是OAuth2
OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容，OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。
2.应用场景
第三方应用授权登录：在APP或者网页接入一些第三方应用时，时长会需要用户登录另一个合作平台，比如QQ，微博，微信的授权登录。
原生app授权：app登录请求后台接口，为了安全认证，所有请求都带token信息，如果登录验证、请求后台数据。
前后端分离单页面应用（spa）：前后端分离框架，前端请求后台数据，需要进行oauth2安全认证，比如使用vue、react后者h5开发的app。
3.名词定义
（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），比如打开知乎，使用第三方登录，选择qq登录，这时候知乎就是客户端。
（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上例的qq。
（3）Resource Owner：资源所有者，本文中又称"用户"（user）,即登录用户。
（4）User Agent：用户代理，本文中就是指浏览器。
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
4.运行流程
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。
5.四种授权模式
授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）
6.授权码模式
授权码模式（authorization code）是功能最完整、流程最严密的授权模式。
流程
说明：【A服务客户端】需要用到【B服务资源服务】中的资源
第一步：【A服务客户端】将用户自动导航到【B服务认证服务】，这一步用户需要提供一个回调地址，以备
【B服务认证服务】返回授权码使用。
第二步：用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】，这一步需要用户登录B服务，也
就是说用户要事先具有B服务的使用权限。
第三步：【B服务认证服务】生成授权码，授权码将通过第一步提供的回调地址，返回给【A服务客户端】。
注意这个授权码并非通行【B服务资源服务】的通行凭证。
第四步：【A服务认证服务】携带上一步得到的授权码向【B服务认证服务】发送请求，获取通行凭证token。
第五步：【B服务认证服务】给【A服务认证服务】返回令牌token和更新令牌refresh token。
使用场景
授权码模式是OAuth2中最安全最完善的一种模式，应用场景最广泛，可以实现服务之间的调用，常见的微
信，QQ等第三方登录也可采用这种方式实现
7.简化模式Implicit
说明：简化模式中没有【A服务认证服务】这一部分，全部有【A服务客户端】与B服务交互，整个过程不再有
授权码，token直接暴露在浏览器。
第一步：【A服务客户端】将用户自动导航到【B服务认证服务】，这一步用户需要提供一个回调地址，以备
【B服务认证服务】返回token使用，还会携带一个【A服务客户端】的状态标识state。
第二步：用户点击授权按钮表示让【A服务客户端】使用【B服务资源服务】，这一步需要用户登录B服务，也
就是说用户要事先具有B服务的使用权限。
第三步：【B服务认证服务】生成通行令牌token，token将通过第一步提供的回调地址，返回给【A服务客户端】。
使用场景
适用于A服务没有服务器的情况。比如：纯手机小程序，JavaScript语言实现的网页插件等
8.用户名密码 Resource Owner Credentials
流程
第一步：直接告诉【A服务客户端】自己的【B服务认证服务】的用户名和密码
第二步：【A服务客户端】携带【B服务认证服务】的用户名和密码向【B服务认证服务】发起请求获取
token。
第三步：【B服务认证服务】给【A服务客户端】颁发token。
使用场景
此种模式虽然简单，但是用户将B服务的用户名和密码暴露给了A服务，需要两个服务信任度非常高才能使用
9.客户端凭证 Client Credentials
流程
说明：这种模式其实已经不太属于OAuth2的范畴了。A服务完全脱离用户，以自己的身份去向B服务索取
token。换言之，用户无需具备B服务的使用权也可以。完全是A服务与B服务内部的交互，与用户无关了。
第一步：A服务向B服务索取token。
第二步：B服务返回token给A服务。
使用场景
A服务本身需要B服务资源，与用户无关。
https://github.com/spring-projects/spring-security-oauth/blob/master/spring-securityoauth2/src/test/resources/schema.sql
| 字段名 | 字段说明 |
| client_id | 主键,必须唯一,不能为空. 用于唯一标识每一个客户端(client); 在注册时必须填写(也可由服务 端自动生成). 对于不同的grant_type,该字段都是必须的. 在实际应用中的另一个名称叫 appKey,与client_id是同一个概念. |
| resource_ids | 客户端所能访问的资源id集合,多个资源时用逗号(,)分隔,如: “unity-resource,mobile resource”. 该字段的值必须来源于与security.xml中标签‹oauth2:resource-server的属性 resource-id值一致. 在security.xml配置有几个‹oauth2:resource-server标签, 则该字段可以 使用几个该值. 在实际应用中, 我们一般将资源进行分类,并分别配置对应 的‹oauth2:resource-server,如订单资源配置一个‹oauth2:resource-server, 用户资源又配置 一个‹oauth2:resource-server. 当注册客户端时,根据实际需要可选择资源id,也可根据不同的 注册流程,赋予对应的资源id. |
| client_secret | 用于指定客户端(client)的访问密匙; 在注册时必须填写(也可由服务端自动生成). 对于不同的 grant_type,该字段都是必须的. 在实际应用中的另一个名称叫appSecret,与client_secret是 同一个概念. |
| scope | 指定客户端申请的权限范围,可选值包括read,write,trust;若有多个权限范围用逗号(,)分隔,如: “read,write”. scope的值与security.xml中配置的‹intercept-url的access属性有关系. 如‹intercept-url的配置为‹intercept-url pattern="/m/**" access=“ROLE_MOBILE,SCOPE_READ”/>则说明访问该URL时的客户端必须有read权限范 围. write的配置值为SCOPE_WRITE, trust的配置值为SCOPE_TRUST. 在实际应该中, 该值一 般由服务端指定, 常用的值为read,write. |
| authorized_grant_types | 指定客户端支持的grant_type,可选值包括 authorization_code,password,refresh_token,implicit,client_credentials, 若支持多个 grant_type用逗号(,)分隔,如: “authorization_code,password”. 在实际应用中,当注册时,该字 段是一般由服务器端指定的,而不是由申请者去选择的,最常用的grant_type组合有: “authorization_code,refresh_token”(针对通过浏览器访问的客户端); “password,refresh_token”(针对移动设备的客户端). implicit与client_credentials在实际中 很少使用. |
| web_server_redirect_uri | 客户端的重定向URI,可为空, 当grant_type为authorization_code或implicit时, 在Oauth的流 程中会使用并检查与注册时填写的redirect_uri是否一致. 下面分别说明:当 grant_type=authorization_code时, 第一步 从 spring-oauth-server获取 'code’时客户端发 起请求时必须有redirect_uri参数, 该参数的值必须与 web_server_redirect_uri的值一致. 第 二步 用 ‘code’ 换取 ‘access_token’ 时客户也必须传递相同的redirect_uri. 在实际应用中, web_server_redirect_uri在注册时是必须填写的, 一般用来处理服务器返回的code, 验证 state是否合法与通过code去换取access_token值.在spring-oauth-client项目中, 可具体参考 AuthorizationCodeController.java中的authorizationCodeCallback方法.当 grant_type=implicit时通过redirect_uri的hash值来传递access_token值. 如:http://localhost:7777/spring-oauth-client/implicit#access_token=dc891f4a-ac88- 4ba6-8224-a2497e013865&token_type=bearer&expires_in=43199然后客户端通过JS等从 hash值中取到access_token值. |
| authorities | 指定客户端所拥有的Spring Security的权限值,可选, 若有多个权限值,用逗号(,)分隔, 如: "ROLE_ |
| 字段名 | 字段说明 |
| access_token_validity | 设定客户端的access_token的有效时间值(单位:秒),可选, 若不设定值则使用默认的有效时间 值(60 * 60 * 12, 12小时). 在服务端获取的access_token JSON数据中的expires_in字段的值 即为当前access_token的有效时间值. 在项目中, 可具体参考DefaultTokenServices.java中属 性accessTokenValiditySeconds. 在实际应用中, 该值一般是由服务端处理的, 不需要客户端 自定义.refresh_token_validity 设定客户端的refresh_token的有效时间值(单位:秒),可选, 若不设定值则使用默认的有效时间值(60 * 60 * 24 * 30, 30天). 若客户端的grant_type不包 括refresh_token,则不用关心该字段 在项目中, 可具体参考DefaultTokenServices.java中属 性refreshTokenValiditySeconds. 在实际应用中, 该值一般是由服务端处理的, 不需要客户端 自定义. |
| additional_information | 这是一个预留的字段,在Oauth的流程中没有实际的使用,可选,但若设置值,必须是JSON格式的 数据,如:{“country”:“CN”,“country_code”:“086”}按照spring-security-oauth项目中对该字段 的描述 Additional information for this client, not need by the vanilla OAuth protocol but might be useful, for example,for storing descriptive information. (详见 ClientDetails.java的getAdditionalInformation()方法的注释)在实际应用中, 可以用该字段来 存储关于客户端的一些其他信息,如客户端的国家,地区,注册时的IP地址等等.create_time 数据的创建时间,精确到秒,由数据库在插入数据时取当前系统时间自动生成(扩展字段) |
| archived | 用于标识客户端是否已存档(即实现逻辑删除),默认值为’0’(即未存档). 对该字段的具体使用请 参考CustomJdbcClientDetailsService.java,在该类中,扩展了在查询client_details的SQL加上 archived = 0条件 (扩展字段) |
| trusted | 设置客户端是否为受信任的,默认为’0’(即不受信任的,1为受信任的). 该字段只适用于 grant_type="authorization_code"的情况,当用户登录成功后,若该值为0,则会跳转到让用户 Approve的页面让用户同意授权, 若该字段为1,则在登录后不需要再让用户Approve同意授权 (因为是受信任的). 对该字段的具体使用请参考OauthUserApprovalHandler.java. (扩展字 段) |
| autoapprove | 设置用户是否自动Approval操作, 默认值为 ‘false’, 可选值包括 ‘true’,‘false’, ‘read’,‘write’. 该 字段只适用于grant_type="authorization_code"的情况,当用户登录成功后,若该值为’true’或 支持的scope值,则会跳过用户Approve的页面, 直接授权. 该字段与 trusted 有类似的功能, 是 spring-security-oauth2 的 2.0 版本后添加的新属性. 在项目中,主要操作 oauth_client_details表的类是JdbcClientDetailsService.java, 更多的细节请参考该类. 也可 以根据实际的需要,去扩展或修改该类的实现. |
| 字段名 | 字段说明 |
| create_time | 数据的创建时间,精确到秒,由数据库在插入数据时取当前系统时间自动生成(扩展字段) |
| token_id | 从服务器端获取到的access_token的值. |
| token | 这是一个二进制的字段, 存储的数据是OAuth2AccessToken.java对象序列化后的二进 制数据. |
| authentication_id | 该字段具有唯一性, 是根据当前的username(如果有),client_id与scope通过MD5加密 生成的. 具体实现请参考DefaultClientKeyGenerator.java类. |
| user_name | 登录时的用户名 |
| client_id |
oauth_client_token表的主要操作在JdbcClientTokenServices.java类中, 更多的细节请参考该类.
oauth_access_token
| 字段名 | 字段说明 |
| create_time | 数据的创建时间,精确到秒,由数据库在插入数据时取当前系统时间自动生成(扩展字段) |
| token_id | 该字段的值是将access_token的值通过MD5加密后存储的. |
| token | 存储将OAuth2AccessToken.java对象序列化后的二进制数据, 是真实的AccessToken 的数据值. |
| authentication_id | 该字段具有唯一性, 其值是根据当前的username(如果有),client_id与scope通过MD5 加密生成的. 具体实现请参考DefaultAuthenticationKeyGenerator.java类. |
| user_name | 登录时的用户名, 若客户端没有用户名(如grant_type=“client_credentials”),则该值等 于client_id |
| client_id | |
| authentication | 存储将OAuth2Authentication.java对象序列化后的二进制数据. |
| refresh_token | 该字段的值是将refresh_token的值通过MD5加密后存储的. 在项目中,主要操作 oauth_access_token表的对象是JdbcTokenStore.java. 更多的细节请参考该类 |
| 字段名 | 字段说明 |
| create_time | 数据的创建时间,精确到秒,由数据库在插入数据时取当前系统时间自动生成(扩展字段) |
| token_id | 该字段的值是将refresh_token的值通过MD5加密后存储的. |
| token | 存储将OAuth2RefreshToken.java对象序列化后的二进制数据. |
| authentication | 存储将OAuth2Authentication.java对象序列化后的二进制数据. |
一样);更多的细节请参考该类. 如果客户端的grant_type不支持refresh_token,则不会使用该表.
oauth_code
| 字段名 | 字段说明 |
| create_time | 数据的创建时间,精确到秒,由数据库在插入数据时取当前系统时间自动生成(扩展字段) |
| code | 存储服务端系统生成的code的值(未加密). |
| authentication | 存储将AuthorizationRequestHolder.java对象序列化后的二进制数据. |
grant_type为"authorization_code"时,该表中才会有数据产生; 其他的grant_type没有使用该表。