OAuth 2.0 介绍

2019-12-10 本文已影响0人鱼da王

是什么？

目前最流行的授权机制，用来授权第三方应用，获取用户数据
为什么出现？
- 用户体验优化：如果用户登录的某个应用，此时还想使用另一个应用，用户只需要授权，无需再输入账户密码即可进入第三方应用。
- 安全：授权后，应用可知晓调用方来源
授权流程是什么？

数据的所有者（比如我的信息）告诉系统（微信），允许第三方应用（QQ）进入系统，获取这些数据。系统产生一个短期的access_token 令牌，来代替用户名密码，供第三方应用进入应用获取我的数据。
令牌设计和密码对比
1. 密码。相当于第三方，完全掌控了授权人在系统中的所有权限，第三方可任意时间进入系统，可进入授权人不想授权的访问数据范围。
2. 令牌
  1. 授权时间的控制
    - 令牌是有时效性。一般防止令牌泄漏的风险，令牌的有效期设置的很短。
  2. 授权发放和撤销的控制
  3. 权限范围控制
    - 只读 & 读写
授权方式- authorization grant
1. 授权码模式（authorization-code）
  1. 大致流程：第三方首先申请到一个授权码，之后通过授权码换取token
  2. 特点
    1. 安全性最高
    2. 授权码通过前端传送，令牌存储在后端
  3. 适用系统：有后端的web应用
  4. 细致流程
    1. A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。
      
      参数
```
https://b.com/oauth/authorize?
  response_type=code&. // 表示要求返回授权码（code）
  client_id=CLIENT_ID& // 表示a的身份
  redirect_uri=CALLBACK_URL& //  B 接受或拒绝请求后的跳转网址
  scope=read  // 表示要求的授权范围（这里是只读）
```
    2. 用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样
```
https://a.com/callback?code=AUTHORIZATION_CODE   // code参数就是授权码
```
    3. A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。
```
https://b.com/oauth/token?
 client_id=CLIENT_ID&
 client_secret=CLIENT_SECRET&  //client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求）
 grant_type=authorization_code&  // 表示采用的授权方式是授权码
 code=AUTHORIZATION_CODE&
 redirect_uri=CALLBACK_URL  // 参数是令牌颁发后的回调网址
```
    4. B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。
```
{    
  "access_token":"ACCESS_TOKEN",  // 令牌
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",  // 令牌过期后，可用此token申请更新
  "scope":"read",
  "uid":100101,
  "info":{...}
}
```
2. 隐藏式（implicit）
  1. 适用系统：纯前端应用
  2. 特点：
    1. 无授权码中间步骤
    2. 很不安全。所以必须要求令牌的有效期必须非常短，通常就是会话期间（session）有效，
  3. 详细步骤
    1. A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。
```
https://b.com/oauth/authorize?
  response_type=token&
  client_id=CLIENT_ID&
  redirect_uri=CALLBACK_URL&
  scope=read
```
    2. 用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站
```
https://a.com/callback#token=ACCESS_TOKEN
```
      注意，令牌的位置是 URL 锚点（fragment）即url “#” 后面的，而不是查询字符串（querystring）即？后面的，这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险
      
      解释：锚点 - 主要资源是由 URI 进行标识，URI 中的 fragment 用来标识次级资源。在 URI 的末尾通过 hash mark（#）作为 fragment 的开头，其中 # 不属于 fragment 的值。
3. 密码式（password）
  1. 特点：
    1. 用户高度信任第三方应用
    2. 风险很大
  2. 流程
    1. A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌
```
https://oauth.b.com/token?
  grant_type=password&  // 授权方式 密码式
  username=USERNAME&
  password=PASSWORD&
  client_id=CLIENT_ID
```
    2. B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌
4. 客户端凭证式（client credentials）
  1. 适用：
    1. 没有前端的命令行应用
    2. 是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。 -- 接口安全验证
  2. 一般saas系统会用到
5. 流程
  1. A 应用在命令行向 B 发出请求。
```
https://oauth.b.com/token?
  grant_type=client_credentials&  // 表示采用凭证式
  client_id=CLIENT_ID&  // B 确认 A 的身份
  client_secret=CLIENT_SECRET  // B 确认 A 的身份
```
    1. B 网站验证通过以后，直接返回令牌。
    2. 之后，A网站每次请求B网站，带着此令牌即可来表明身份。一般还会进行验签，保证安全
令牌的使用
1. A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。
2. 具体做法：在请求的头信息，加上一个Authorization字段
```
curl -H "Authorization: Bearer ACCESS_TOKEN" \
"https://api.b.com"
```
  上面命令中，ACCESS_TOKEN就是拿到的令牌。
更新令牌

令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。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
```
B 网站验证通过以后，就会颁发新的令牌。

参考：

OAuth2.0简单介绍：http://www.ruanyifeng.com/blog/2019/04/oauth_design.html
OAuth2.0四种授权方式：http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
第三方登录示例：http://www.ruanyifeng.com/blog/2019/04/github-oauth.html

OAuth 2.0 介绍

猜你喜欢

热点阅读