Oauth 2.0介绍

Oauth 2.0

Oauth2.0是一种授权机制，用来授权第三方应用，获取用户数据。例如快递需要进入小区送货但是没有门卡进入相同。这里相当于给了快递小哥权限进入小区权限，每次进入都需要征求户主同意一样。

token 与password的区别：

token是短期的，到期就会自动失效，用户无法自己修改，password长期有效，用户不进行修改，就不会发生变化
token可以被数据所有者撤销，会立即失效
token有权限范围scope，而password一般是完整权限

Oauth 2.0的标准是RFC 6749。该文件解释了Oauth是什么
客户端通过令牌，去请求数据

同时RFC 6749标准定义了获取令牌的四种授权方式（authorization grant）

• 授权码authorization-code
• 隐藏式implicit
• 密码式 password
• 客户端凭证client credentials

授权方式解释说明

授权码

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

第一步：A网站提供一个链接，用户点击后就会跳转到B网站，授权用户数据给A网站使用，如下所示

https://b.com/oauth/authorize?
  response_type=code&                       #要求返回授权码
  client_id=CLIENT_ID&                      #让B知道是谁在请求
  redirect_uri=CALLBACK_URL&                #B接受或拒绝请求后的跳转网址
  scope=read                                #表示要求的授权范围

第二步，B网站会要求用户登录，然后询问是否同意给与A网站授权。用户表示同意，这时B网站就会跳回redirect_uri参数指定的网站，会传回一个授权码，如下

https://a.com/callback?code=AUTHORIZATION_CODE         #code参数就是授权码

第三步，A网站拿到授权码以后，就可以在后端，向B网站请求令牌

https://b.com/oauth/token?
 client_id=CLIENT_ID&                         #client_id参数和client_secret参数用来让B确认A的身份
 client_secret=CLIENT_SECRET&
 grant_type=authorization_code&        #该参数的值是authorization_code，表示采用的授权方式是授权码
 code=AUTHORIZATION_CODE&               #code参数是上一步拿到的授权码
 redirect_uri=CALLBACK_URL              #令牌颁发后的回调地址

第四步，B网站收到请求后，就会颁发令牌，具体做法是向redirect_uri指定的网址

{    
  "access_token":"ACCESS_TOKEN",    #令牌
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

隐藏式

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）。

第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

https://b.com/oauth/authorize?
  response_type=token&     #直接返回令牌
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read

第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。
https://a.com/callback#token=ACCESS_TOKEN

密码式

如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
第一步，A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌。

https://oauth.b.com/token?
  grant_type=password&
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID

第二步，B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌。
这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

凭证式

适用于没有前端的命令行应用，即在命令行下请求令牌。
第一步，A 应用在命令行向 B 发出请求。

https://oauth.b.com/token?
  grant_type=client_credentials&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET

第二步，B 网站验证通过以后，直接返回令牌。
这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

令牌的使用

A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。

此时，每个发到 API 的请求，都必须带有令牌。具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"

令牌的更新

OAuth 2.0 允许用户自动更新令牌。
具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

https://b.com/oauth/token?
  grant_type=refresh_token&
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  refresh_token=REFRESH_TOKEN

注：内容来源于网络，该博客只为记录知识点。

来源：CSDN

作者：等风来也chen

链接：https://blog.csdn.net/weixin_44267608/article/details/103493492