1.1 Oauth2认证流程:
1.2 Token携带相关参数注释:
首先讲下资源与授权服务配置注解:
请求优先@EnableAuthorizationServer,@EnableResourceServer处理,剩下的无法匹配的由SpringSecurity处理
2.1资源服务器配置:
2.2其他属性：
accessDeniedHandler 授权失败且主叫方已要求特定的内容类型响应
resourceTokenServices加载 OAuth2Authentication 和 OAuth2AccessToken 的接口
eventPublisher 事件发布-订阅 根据异常的clazz触发不同event
2.2 授权服务器配置(两种方式)：
A.手动:
B.直接用数据库:
2.3 配置授权服务器端点,如:令牌存储;令牌自定义;用户批准和授权类型 以及配置服务器端点的安全
2.4 yml配置例子(以github作为认证服务器):
2.5 引入依赖
授权有授权码模式;隐式授权模式;密码模式;客户端模式;常用授权码和密码,介绍如下:
3.1 授权码模式:
参数列表如下：
client_id：客户端id，和授权配置类中设置的客户端id一致。
response_type：授权码模式固定为code
scop：客户端范围，和授权配置类中设置的scop一致。
redirect_uri：跳转uri，当授权码申请成功后会跳转到此地址，并在后边带上code参数（授权码）。
拿到授权码后申请令牌:
参数解释:
Access_token:访问令牌,客户端拿着访问令牌即可向服务提供方获取相应资源或信息
Refresh_token:刷新令牌,由于访问令牌是有失效时间的,所以一般情况下都是在访问令牌即将失效时使用刷新令牌可重新获取新的访问令牌
token_type：有MAC Token与Bearer Token两种类型，两种的校验算法不同，RFC 6750建议Oauth2采用 Bearer Token（http://www.rfcreader.com/#rfc6750）。
expires_in：过期时间，单位为秒。
scope：范围，与定义的客户端范围一致。
3.2 资源服务器授权配置:
1 配置公钥:
3 在config包下创建ResourceServerConfig类
4 资源服务器测试是否携带令牌以及令牌是否有效:
注:若不携带令牌或令牌过期或错误则无法验证一般报如下错误:
3.3 密码模式:(相对授权码而言少了一步授权码获取 由用户直接将用户名密码传给客户端 客户端直接拿着这两个去申请令牌)
参数:
grant_type：密码模式授权填写password
username：账号
password：密码
上边参数使用x-www-form-urlencoded方式传输，使用postman测试如下：
参数:
client_id：客户端准入标识。
client_secret：客户端秘钥。
grant_type：授权类型，填写password表示密码模式
username：资源拥有者用户名。
password：资源拥有者密码
注意：当令牌没有过期时同一个用户再次申请令牌则不再颁发新令牌。
校验令牌:
校验成功则会返回与该令牌绑定的相关用户信息
参数列表:
exp：过期时间，long类型，距离1970年的秒数（new Date().getTime()可得到当前时间距离1970年的毫秒数）。
user_name： 用户名
client_id：客户端Id，在oauth_client_details中配置
scope：客户端范围，在oauth_client_details表中配置
jti：与令牌对应的唯一标识
companyId、userpic、name、utype、id：这些字段是本认证服务在Spring Security基础上扩展的用户身份信息
刷新令牌的使用
生成一个新的访问令牌
grant_type ： 固定为 refresh_token
refresh_token：刷新令牌（注意不是access_token，而是refresh_token）
注:刷新令牌成功，会重新生成新的访问令牌和刷新令牌，令牌的有效期也比旧令牌长。
刷新令牌通常是在令牌快过期时进行刷新。
Xml配置:
3.4 WebSecurityConfig中HttpSecurity一些参数解释:
3.5 Jwt令牌:
jwt与token的验证思路区别:
Token:后端接收到前端传过来的token,若果是通过数据库或redis或session进行对比验证,这种方式为令牌验证
用户输入用户名和密码，发送给服务器。
服务器验证用户名和密码，正确的话就返回一个签名过的token（token 可以认为就是个长长的字符串），浏览器客户端拿到这个token。
后续每次请求中，浏览器会把token作为http header发送给服务器，服务器验证签名是否有效，如果有效那么认证就成功，可以返回客户端需要的数据。 特点： 这种方式的特点就是客户端的token中自己保留有大量信息，服务器没有存储这些信息。
Jwt:后端接收到前端传过来的token,如果是通过一套加密解密算法(RSA)来确定用户的身份是否合法,这种方式为jwt(Header头部(令牌的类型（即JWT）及使用的哈希算法（如HMACSHA256或RSA）)，Payload负载(内容也是一个json对象，它是存放有效信息的地方，它可以存放jwt提供的现成字段，比如：iss（签发者）,exp（过期时间戳）,sub（面向的用户）等，也可自定义字段。此部分不建议存放敏感信息，因为此部分可以解码还原原始内容。最后将第二部分负载使用Base64Url编码，得到一个字符串就是JWT令牌的第二部分)和Signature签名(用于防止jwt令牌被篡改)。由三部分生成token，三部分之间用“.”号做分割)
2 生成公钥和私钥:
参数解释:
Keytool是一个java提供的证书管理工具
-alias：密钥的别名
-keyalg：使用的hash算法
-keypass：密钥的访问密码
-keystore：密钥库文件名，
xc.keystore保存了生成的证书
-storepass密钥库的访问密码
查询证书信息:
Keytool -list -keystore wang.keystore
删除别名:
Keytool -delete -alias xckey -keystore wang.keystore
3 导出公钥:
需要先下载openssl(加解密工具
包):http://slproweb.com/products/Win32OpenSSL.html并配置对应的环境变量
4 cmd进入wang.keystore所在目录执行:
keytool -list -rfc --keystore wang.keystore | openssl x509 -inform pem -pubkey
上半部即为公钥 将其放到编辑器 调整为一行
生成jwt令牌:
校验令牌:
结果:
