[[332754]]

本文轉載自微信公眾號「程序員內點事 」，作者程序員內點事。轉載本文請聯系程序員內點事公眾號。

上周我的自研開源項目開始破土動工了，《開源項目邁出第一步，10 選 1?頁面模板成了第一個絆腳石 》 ，密謀很久才付諸行動，做這個的初衷就是不想讓自己太安穩，技術這條路不進步就等于后退，必須要逼著自己學習。

項目偏向于技術實踐，因此不會做太多的業務堆砌，業務代碼還是在公司學習比較好。現在正在做技術的選型與儲備，像比較主流的，項目前后端分離、微服務、Springboot、Springcloud 等都會應用到項目中，其實很多技術我也不會，也是在反復的查閱資料求證，探索的過程技術提升真的要比工作中快很多，畢竟主動與被動學習是有本質區別的。

這幾天打算先把項目的前后端分離架構搭建完成，既然是前后端分離項目就免不了做鑒權， 所以 oauth2.0 是一個我們不得不了解的知識點。

一、OAuth2.0 為何物

OAuth 簡單理解就是一種授權機制，它是在客戶端和資源所有者之間的授權層，用來分離兩種不同的角色。在資源所有者同意并向客戶端頒發令牌后，客戶端攜帶令牌可以訪問資源所有者的資源。

OAuth2.0 是OAuth 協議的一個版本，有2.0版本那就有1.0版本，有意思的是OAuth2.0 卻不向下兼容OAuth1.0 ，相當于廢棄了1.0版本。

舉個小栗子解釋一下什么是 OAuth 授權?

在家肝文章餓了定了一個外賣，外賣小哥30秒火速到達了我家樓下，奈何有門禁進不來，可以輸入密碼進入，但出于安全的考慮我并不想告訴他密碼。

此時外賣小哥看到門禁有一個高級按鈕“一鍵獲取授權”，只要我這邊同意，他會獲取到一個有效期 2小時的令牌(token)正常出入。

令牌(token)和 密碼 的作用雖然相似都可以進入系統，但還有點不同。token 擁有權限范圍，有時效性的，到期自動失效，而且無效修改。

二、OAuth2.0 授權方式

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、授權碼

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 

用戶同意授權后，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、隱藏式

上邊提到有一些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 

3、密碼式

密碼模式比較好理解，用戶在掘金直接輸入自己的WX用戶名和密碼，掘金拿著信息直接去WX申請令牌，請求響應的 JSON結果中返回 token。grant_type 為 password 表示密碼式授權。

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

這種授權方式缺點是顯而易見的，非常的危險，如果采取此方式授權，該應用一定是可以高度信任的。

4、憑證式

憑證式和密碼式很相似，主要適用于那些沒有前端的命令行應用，可以用最簡單的方式獲取令牌，在請求響應的 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 

三、令牌的使用與更新

1、令牌怎么用?

拿到令牌可以調用 WX API 請求數據了，那令牌該怎么用呢?

每個到達WX的請求都必須帶上 token，將 token 放在 http 請求頭部的一個Authorization字段里。

如果使用postman 模擬請求，要在Authorization -> Bearer Token 放入 token，注意：低版本postman 沒有這個選項。

2、令牌過期怎么辦?

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 

總結

OAuth2.0 授權其實并不是很難，只不過授權流程稍顯麻煩，邏輯有些繞，OAuth2.0它是面試經常會被問到的知識點，還是應該多了解一下。

原文鏈接：https://mp.weixin.qq.com/s/in_E1pKqQc8wkPXT61g8gQ