OAuth2是什么?
OAuth是一个为了方便用户登入而使用的授权流程，他的优点是不需要向第三方平台暴露我们的用户名和密码，而是使用授权服务器颁发短期的token和效验token的方式开放部分资源给第三方平台
OAuth是一个授权协议不是认证协议
OAuth2的授权方式
授权方式第一种: 授权码 (最安全使用最多的方式)
这种方式合适存在后端平台
存在这么一个资源(扣扣头像)和资源拥有者(扣扣号主), 现在喝了么(假设需要授权的平台)需要获取扣扣人头像。
那么现在的步骤是
获取access token 请求
获取access token
放在实际体验上就是
- 用户同意授权服务器生成token
喝了么想到获得扣扣的授权, 所以组合了个扣扣的网址访问
koukou.com/oauth/autho…
这里有几个参数需要喝了么平台的开发人员提供:
response_type ==> 表示要求返回授权码code
client_id ==> 让扣扣平台知道是谁在访问授权服务器(这个需要去扣扣开发者平台)
redirect_uri ==> 这是扣扣授权完成后跳转到喝了么的网站 比如：https://heleme.com/callback?code=AUTHORIZATION_CODE 这个网址在controller里面写好了, 参数必须和扣扣官方给的网址一样
scope ==> 表示授权权限, 比如只读或者读写之类
打开上面的网站后, 会打开扣扣的平台要求扫码登入(这里就是用户是否同意授权步骤)，如果扫码成功授权登入则会使用前面的redirect_uri这个参数填写的网址,但参数code的值AUTHORIZATION_CODE将会被扣扣平台改写成扣扣授权服务器生成的code(这个 code 就是授权码) 假设这里拿到的授权码是 123456
授权码的作用就是让扣扣用户同意授权服务器生成token的请求
至此喝了么已经拿到了授权码接下来就是oauth授权获取token的过程了
- 喝了么获得授权码后拿着授权码再次去找授权服务器拿token
koukou.com/oauth/token…
client_id ==> 客户的id
client_secret ==> 扣扣开发平台可以获得这个参数, 主要用于扣扣识别用户喝了么
grant_type ==> 固定authorization_code, 表示使用授权码类型获取token
code ==> 授权码, 前面已经拿到了直接填上123456
redirect_uri ==> 重定向到喝了么平台获取token的网址(这个网址就是controller上写, 参数必须和扣扣官方给的网址一样)
等到获取token任务完成后, 就会自动跳转到喝了么重定向网址, 并向这个网址发送JSON数据, 里面存放着token
{
"access_token":"ACCESS_TOKEN",
"token_type":"bearer",
"expires_in":2592000,
"refresh_token":"REFRESH_TOKEN",
"scope":"read",
"uid":100101,
"info":{...}
}
复制代码此时喝了么就拿到了ACCESS_TOKEN, 接下来, 我们就可以借助这个token完成我们所需要的任务
授权方式第二种: 简化模式
简化模式主要用于前端与前端之间的token授权, 这种模式没有后端
还是喝了么和扣扣之间的关系, 喝了么需要借助扣扣帐号进行授权
koukou.com/oauth/autho…
参数1: response_type 一般填写token就可以了
参数2: client_id 一般是开发平台获取
参数3: redirect_uri 主要是重定向的地址, 如果扣扣平台授权完毕之后将会跳转到喝了么提供的重定向网址, 并且扣扣平台会修改重定向地址的参数, 将token放入到参数中
参数4: scope token拥有的权限, 只读 只写 或者 读写
heleme.com/callback#to…
这是redirect_uri重定向的地址, 参数token=ACCESS_TOKEN, 这里的ACCESS_TOKEN有扣扣平台提供
至此我们就可以在java中的controller中获取到access_token, 将它存储下来便可, 以后某些操作需要带上token即可
授权方式第三种: 密码模式
这种模式合适公司内部使用, 因为需要暴露用户名和密码
这种模式资源拥有者直接将用户名和密码给客户端, 客户端使用用户名密码登入授权服务器, 授权服务器验证并返回access token给客户端
这种模式一般使用在企业内部
授权方式第四种: 客户端模式
客户端将认证信息发送给授权服务器, 授权服务器返回access token
一般使用在机器对机器之间的联系, 没有资源拥有者角色
刷新令牌
刷新令牌的方式主要为了便捷授权流程, 在客户端获取授权之后返回access token的同时带上 refresh token给客户端, 等下次客户端获取数据是带上access token便可, 但有一天access token失效了, 正常模式下需要重新走授权流程, 但如果存在refresh token时客户端只要把自己的refresh token发送给授权服务器, 授权服务器就会跳过授权过程, 直接发送一个新的access token给客户端
OAuth选型
授权服务器的组成
授权服务器包括4个端点
- 授权端点
- token颁发端点
- 验证端点
- 撤回端点