假設你要開發(fā)一個中醫(yī)問診平臺，該平臺可以根據用戶的中藥飲片購買記錄來智能地計算用戶可能具有的中醫(yī)癥狀，并自動推薦相關的中醫(yī)專家。這樣的話，用戶為了使用問診服務，就必須讓平臺讀取自己在藥房上的藥品購買記錄。

那么問題就來了，問診平臺怎么樣才能獲得用戶的授權呢？一般我們想到的是，用戶將自己的藥房用戶名和密碼告訴問診平臺，然后問診平臺就可以通過用戶名和密碼登錄到藥房并讀取用戶的購藥記錄。

圖片

這個方案雖然可行，但存在幾個明顯的漏洞。首先，問診平臺為了開展后續(xù)的服務，會保存用戶在藥房上的密碼，這樣很不安全；其次，問診平臺擁有了獲取用戶存儲在藥房上所有資料的權力，用戶沒法限制問診平臺獲得授權的范圍和有效期；最后，用戶只有修改密碼，才能收回賦予問診平臺的權力，但是這樣做會使得其他所有獲得用戶授權的類似問診平臺的第三方應用程序全部失效。而且只要有一個第三方應用程序被破解，就會導致用戶密碼泄漏，以及所有被密碼保護的數據產生泄漏。

聽著是不是很可怕？沒事的，我們有 OAuth2.0 協議。與傳統(tǒng)方法相比，OAuth2 協議具有一系列的優(yōu)勢。

首先，針對密碼的安全性，在 OAuth2 協議中，密碼還是由用戶自己保管，避免了敏感信息的泄露；其次，OAuth2 協議中所提供的授權具有明確的應用范圍和有效期，用戶可以根據需要限制問診平臺所獲取授權信息的作用效果；最后，用戶如果對自己的密碼等身份憑證信息進行了修改，那么只要通過 OAuth2 協議重新進行一次授權即可，不會影響到相關聯的其他第三方應用程序。

圖片

為什么 OAuth2 協議能有這些優(yōu)勢呢？這是因為它有著四個核心的角色，資源、客戶端、授權服務器和資源服務器。

圖片

OAuth2 協議中把需要訪問的接口或服務統(tǒng)稱為資源（Resource），每個資源都有一個擁有者（Resource Owner）,也就是案例中的用戶?？蛻舳耸侵嗅t(yī)問診平臺，也就是第三方應用程序（Third-party Application）。而藥房，在案例中的角色是服務提供商，服務提供商中的資源服務器存放著用戶資源，案例中的用戶購藥記錄就是一種用戶資源。而授權服務器則對資源擁有者的身份進行認證，完成授權審批流程，并最終頒發(fā)一個訪問令牌（Access Token）。

你一定要注意這個訪問令牌。它是 OAuth2 協議中非常重要的一個概念，本質上也是一種代表用戶身份的授權憑證，但與普通的用戶名和密碼信息不同，令牌具有針對資源的訪問權限范圍和有效期。

{
    "access_token": "b7c2c7e0-0223-40e2-911d-eff82d125b80",
    "token_type": "bearer",
    "refresh_token": "40ee99d5-90f6-43ce-920f-383a619fc806",
    "expires_in": 43199,
    "scope": "webclient"
}

這段代碼中的 access_token 就是 OAuth2 的令牌，當訪問每個受保護的資源時，用戶都需要攜帶這個令牌以便進行驗證。

• 針對 token_type，OAuth2 協議中有很多中可選的令牌類型，包括 bearer 類型、mac 類型等，這里指定的是最常見的一種類型，就是 bearer 類型；
• expires_in 屬性用于指定 access_token 的有效時間，當超過這個有效時間的時候，access_token 將會自動失效。
• refresh_token 的作用在于，當 access_token 過期之后，重新下發(fā)一個新的 access_token；
• scope 指定了可訪問的權限范圍，這里指定的是訪問 Web 資源的“webclient”。

那這個令牌到底有什么用呢？最大的用處就是我們可以用令牌來完成基于 OAuth2 協議的授權工作流程。也就是：

圖片

• 客戶端請求用戶的授權，請求中一般包含資源的訪問路徑、對資源的操作類型等信息
• 用戶同意給予客戶端授權，并將這個授權發(fā)送給客戶端
• 客戶端向授權服務器請求訪問令牌。此時，客戶端需要向授權服務器提供上一步獲取的授權信息，以及客戶端自身的有效身份憑證
• 授權服務器驗證通過后，向客戶端返回訪問令牌
• 客戶端攜帶訪問令牌訪問資源服務器上的資源。在令牌的有效期內，客戶端可以多次攜帶令牌去訪問資源。
• 資源服務器驗證令牌的有效性以及是否過期，驗證通過后才能開放服務。

在整個工作流程中，最為關鍵的是第二步，只有獲取了這個授權之后，客戶端才可以獲取令牌，進而憑令牌獲取資源。那么用戶如何才能獲取客戶端授權呢？在 OAuth 2.0 中，定義了四種授權方式，即授權碼模式（Authorization Code）、簡化模式（Implicit）、密碼模式（Password Credentials）和客戶端模式（Client Credentials）：

圖片

授權碼模式功能最完整，流程也最嚴密，當用戶同意授權后，授權服務器不是馬上返回最終的令牌，而是一個授權碼，需要客戶端攜帶授權碼去換令牌，這就需要客戶端自身具備與授權服務器進行直接交互的后臺服務。

圖片

• 用戶訪問客戶端，客戶端會將用戶導向授權服務器。
• 用戶選擇是否給予客戶端授權。
• 假設用戶給予授權，授權服務器將用戶導回客戶端事先指定的回調地址，同時附上一個授權碼。
• 客戶端收到授權碼，并附上回調地址，向授權服務器申請令牌。這一步是在客戶端系統(tǒng)的后臺服務上完成的，對用戶不可見。
• 授權服務器核對授權碼和回調地址，確認無誤后，向客戶端發(fā)送訪問令牌。

我們再來看另一種比較常用的密碼模式。它比較簡單，也更加容易理解。

圖片

在密碼模式下，用戶向客戶端提供用戶名和密碼，然后客戶端將用戶名和密碼發(fā)給授權服務器并請求令牌，授權服務器確認無誤后，就會向客戶端發(fā)放令牌。就目前主流的微服架構來說，當我們發(fā)起 HTTP 請求時，關注的是如何通過 HTTP 協議透明而高效的傳遞令牌，授權碼模式下通過回調地址進行授權管理的方式就不是很實用，密碼模式反而更加簡潔高效。

OAuth2 中的客戶端模式和簡化模式因為在日常開發(fā)過程中應用得不是很多，這里就不詳細介紹了。

你可能注意到，雖然說 OAuth2 協議解決的是授權問題，但它也應用到了認證的概念，因為只有驗證了用戶的身份憑證，我們才能完成對他的授權。所以說，OAuth2 實際上是一款技術體系比較復雜的協議，綜合應用了信息摘要、簽名認證等安全性手段，并需要提供令牌以及背后的公私鑰管理等功能。