微服务 —— OAuth2.0详解｜8月更文挑战

这是我参与8月更文挑战的第21天，活动详情查看：8月更文挑战

OAuth2.0 的授权简单理解其实就是获取令牌（token）的过程，OAuth 协议定义了四种获得令牌的授权方式（authorization grant ）如下：

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

但值得注意的是，不管我们使用哪一种授权方式，在三方应用申请令牌之前，都必须在系统中去申请身份唯一标识：客户端 ID（client ID）和 客户端密钥（client secret）。这样做可以保证 token 不被恶意使用。

下面我们会分析每种授权方式的原理，在进入正题前，先了解 OAuth2.0 授权过程中几个重要的参数：

• response_type：code 表示要求返回授权码，token 表示直接返回令牌
• client_id：客户端身份标识
• client_secret：客户端密钥
• redirect_uri：重定向地址
• scope：表示授权的范围，read只读权限，all读写权限
• grant_type：表示授权的方式，AUTHORIZATION_CODE（授权码）、password（密码）、client_credentials（凭证式）、refresh_token 更新令牌
• state：应用程序传递的一个随机数，用来防止CSRF

1 授权码模式

授权码模式（Authorization Code Grant）。

• 第一步：用户访问页面
• 第二步：访问的页面将请求重定向到认证服务器
• 第三步：认证服务器向用户展示授权页面，等待用户授权
• 第四步：用户授权，认证服务器生成一个code和带上client_id发送给应用服务器。然后，应用服务器拿到code，并用client_id去后台查询对应的client_secret
• 第五步：将code、client_id、client_secret传给认证服务器换取access_token和 refresh_token
• 第六步：将access_token和refresh_token传给应用服务器
• 第七步：验证token，访问真正的资源页面

掘金授权案例

OAuth2.0四种授权中授权码方式是最为复杂，但也是安全系数最高的，比较常用的一种方式。这种方式适用于兼具前后端的Web项目，因为有些项目只有后端或只有前端，并不适用授权码模式。下图我们以用WX登录掘金为例，详细看一下授权码方式的整体流程。

用户选择WX登录掘金，掘金会向WX发起授权请求，接下来 WX询问用户是否同意授权（常见的弹窗授权）。其中 response_type 为 code 要求返回授权码，scope 参数表示本次授权范围为只读权限，redirect_uri 重定向地址。

 https://wx.com/oauth/authorize?
   response_type=code&
   client_id=CLIENT_ID&
   redirect_uri=http://juejin.im/callback&
   scope=read&
   state=10001

用户同意授权后，WX 根据 redirect_uri重定向并带上授权码。

 http://juejin.im/callback?code=AUTHORIZATION_CODE

当掘金拿到授权码（code）时，带授权码和密匙等参数向WX申请令牌。grant_type表示本次授权为授权码方式 authorization_code ，获取令牌要带上客户端密匙 client_secret，和上一步得到的授权码 code。

 https://wx.com/oauth/token?
  client_id=CLIENT_ID&
  client_secret=CLIENT_SECRET&
  grant_type=authorization_code&
  code=AUTHORIZATION_CODE&
  redirect_uri=http://juejin.im/callback

最后 WX 收到请求后向 redirect_uri 地址发送 JSON 数据，其中的access_token 就是令牌。

  {    
   "access_token":"ACCESS_TOKEN",
   "token_type":"bearer",
   "expires_in":2592000,
   "refresh_token":"REFRESH_TOKEN",
   "scope":"read",
   ......
 }

2 简化模式

简化模式（Implicit Grant）。

• 第一步：用户访问页面时，重定向到认证服务器
• 第二步：认证服务器给用户一个认证页面，等待用户授权
• 第三步：用户授权，认证服务器想应用页面返回Token
• 第四步：验证Token，访问真正的资源页面

3 密码模式

密码模式（Resource Owner Password Credentials Grant）。

• 第一步：用户访问用页面时，输入第三方认证所需要的信息(QQ/微信账号密码)
• 第二步：应用页面那种这个信息去认证服务器授权
• 第三步：认证服务器授权通过，拿到token，访问真正的资源页面

优点：不需要多次请求转发，额外开销，同时可以获取更多的用户信息。

缺点：局限性，认证服务器和应用方必须有超高的信赖。

应用场景：自家公司搭建的认证服务器。

4 客户端模式

客户端模式（Client Credentials Grant）。

• 第一步：用户访问应用客户端
• 第二步：通过客户端定义的验证方法，拿到token，无需授权
• 第三步：访问资源服务器A
• 第四步：拿到一次token就可以畅通无阻的访问其他的资源页面。

这是一种最简单的模式，只要client请求，我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。

4 隐藏式

上边提到有一些Web应用是没有后端的， 属于纯前端应用，无法用上边的授权码模式。令牌的申请与存储都需要在前端完成，跳过了授权码这一步。前端应用直接获取 token，response_type 设置为 token，要求直接返回令牌，跳过授权码，WX授权通过后重定向到指定 redirect_uri 。

 https://wx.com/oauth/authorize?
   response_type=token&
   client_id=CLIENT_ID&
   redirect_uri=http://juejin.im/callback&
   scope=read

5 密码式

密码模式比较好理解，用户在掘金直接输入自己的WX用户名和密码，掘金拿着信息直接去WX申请令牌，请求响应的 JSON结果中返回 token。grant_type 为 password 表示密码式授权。

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

这种授权方式缺点是显而易见的，非常的危险，如果采取此方式授权，该应用一定是可以高度信任的。

7 凭证式

凭证式和密码式很相似，主要适用于那些没有前端的命令行应用，可以用最简单的方式获取令牌，在请求响应的 JSON 结果中返回 token。grant_type 为 client_credentials 表示凭证式授权，client_id 和 client_secret 用来识别身份。

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

8 常见问题

问题一：令牌怎么用？

拿到令牌可以调用 WX API 请求数据了，那令牌该怎么用呢？每个到达WX的请求都必须带上 token，将 token 放在 http 请求头部的一个Authorization字段里。如果使用postman 模拟请求，要在Authorization -> Bearer Token 放入 token，注意：低版本postman 没有这个选项。

问题二：令牌过期怎么办？

token是有时效性的，一旦过期就需要重新获取，但是重走一遍授权流程，不仅麻烦而且用户体验也不好，那如何让更新令牌变得优雅一点呢？一般在颁发令牌时会一次发两个令牌，一个令牌用来请求API，另一个负责更新令牌 refresh_token。grant_type 为 refresh_token 请求为更新令牌，参数 refresh_token 是用于更新令牌的令牌。

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