隨着互聯網技術的發展，微服務架構已經成爲每個互聯網公司的標配。伴隨着服務粒度的細化，服務的安全和鑑權問題，以及客戶端與服務之間的認證問題已經成爲必不可少的一項工作。說起認證和鑑權，那怎麼少得了 OAuth 2.0 協議呢？
火鍋店旁邊的照片打印機
這個案例想必大家都遇到過，在商場裏面或者餐館門口會看到一些可以打印照片的設備。想要設備打印出照片那麼必須傳輸照片給設備，但是假如此時由於你的手機設備存儲有限，美美的照片被存儲在了百度雲盤。那麼如何讓設備獲取到你存儲在雲盤的照片呢？聰明的你肯定已經想到對策了。
1. 賬戶和密碼
這種方式最爲簡單直接，但是一旦你將賬戶和密碼告訴第三種應用，第三方應用就會無所不能，隨意操作你的賬戶不受你的管控。你唯一能做的就是更改掉舊的密碼，這樣才能收回你的權限。
2. 開發者鑰匙
這種方式需要先在資源提供方申請開發者鑰匙，它建立在客戶應用和資源方是互相信任的情況下。但是這種方式也會存在開發者鑰匙泄露的情況，一旦泄露給不法分子，安全同樣會受到威脅。
3. 特殊令牌
這種方式是資源方提供一個令牌給客戶應用，通過令牌，客戶應用可以訪問資源。但是資源方頒發的令牌會受到權限的控制，並且會在有效期終止後自動銷燬。
上述特殊令牌的方式即爲我們今天即將要討論的 OAuth 2.0，OAuth 2.0 會解決令牌涉及到的一系列問題。那麼 OAuth 2.0 的令牌可以用來解決哪些問題呢？
開放系統間的授權
1. 社交聯合登錄
想必你在登錄一個網站或者應用時候，一定遇到可以通過第三方的應用賬戶登錄的案例。例如你在給一些技術博客做評論的時候需要登錄，你又沒有該博客的賬戶，但是你可以通過 GitHub 賬戶登錄然後評論。
2. 開放接口平臺
還是 GitHub 的例子，你不但可以直接去 GitHub 的網站上操作賬戶，你也可以通過 GitHub 提供的開放 API 來操作你的 GitHub 賬戶。有興趣可以去了解一下：GitHub API。
微服務安全問題
微服務將應用拆成多個小的應用接口服務，但是各個服務之間的業務難免會有所依賴，此時服務之間的調用也需要有安全的保證。同時客戶端的接入也會變得複雜，例如：單頁面應用、原生應用、Web App 等。這些應用的接入都需要得到安全保證，OAuth 2.0 可以幫助我們解決這些問題。
內部應用授權
企業內部應用繁多，例如代碼平臺、應用發佈平臺、OA 系統等。如果爲這些系統分別都創建一個賬戶，那麼這對我們員工來說將是一個災難，我們要記住每個賬戶和密碼，每個系統都需要分別登錄。因此有點規模的企業都需要一套單點登錄的服務，我們可以通過 OAuth 2.0 來實現企業級的 SSO（單點登錄） 服務。
初步認識 OAuth 2.0
如下圖所示，OAuth 2.0 中包含四個重要的參與者：資源擁有者、客戶應用、受保護資源、授權服務器。下面我們就詳細說說 OAuth 2.0 的工作流程，它主要分爲以下幾個步驟：
- 首先資源擁有者在客戶應用中發起對受保護資源的訪問請求。
- 客戶應用向資源服務器發起授權請求。
- 資源擁有者通過客戶應用代理授予客戶應用訪問資源的權限。
- 授權服務器得到資源擁有者的指令，向客戶應用頒發訪問令牌。
- 客戶應用獲得受限的權限令牌，訪問受保護的資源。
如上幾個步驟即爲 OAuth 2.0 的主要工作流程。當然其中還有少許細節，客戶應用在獲得令牌後，第二次訪問資源就可以直接使用第一次獲取的令牌來訪問，無需再次獲取。當然令牌也會過期，過期後客戶應用需要重新獲取授權，這是不是聽起來很麻煩呢？OAuth 2.0 支持刷新令牌，即客戶應用在令牌過期後，可以直接使用刷新令牌獲得新的令牌，這樣就省去了重新授權的複雜過程。
OAuth2 到底是什麼
定義
上面我們介紹了 OAuth 2.0 的應用場景，以及它的工作流程，是時候來給出 OAuth 2.0 的定義了。
OAuth 2.0 是一個基於令牌 Token 的授權協議，通過它我們可以在不暴露賬戶和密碼的情況下授予客戶應用有限的數據訪問權限。它解藕了認證和授權，同時它是事實上的安全框架，它能支持服務與服務，App、單頁面應用與後端服務等很多應用場景。
授權模式
OAuth 2.0 共有如下四種授權模式，通過下面的任意一種方式，客戶應用都可以獲得授權令牌來訪問受保護的資源。
授權碼模式
這種方式是最複雜但也是最安全的方式。資源所有者授予客戶應用訪問權限後，授權服務器首次發放給客戶應用的是一個授權碼，隨後客戶應用在服務器端直接向授權服務器發起兌換授權令牌請求，這樣纔會獲得真正的訪問令牌。這種方式雖然複雜，但是你注意到訪問令牌是客戶應用服務器端代碼直接發起的操作，並未通過終端代理，它提高了授權令牌的安全性。一般用於 Web 應用或者原生 App，這樣 Token 就不會經過瀏覽器和 App，這樣大大降低了 Token 泄漏的風險。
簡化模式
這種方式是授權碼模式的一個簡化版本，資源所有者授權後，授權服務器直接將令牌發放至代理終端（例如瀏覽器），省去了授權碼的流程。這種方式一般用於沒有服務器的單頁面應用，因爲他們沒有服務器端去拿授權碼換取 Token。
密碼模式
這種方式是資源擁有者直接將賬戶和密碼告訴客戶應用，客戶應用使用賬戶和密碼去授權服務器換取 Token。這種模式一般應用於企業內部的應用，應用之間是完全可信的，都是第一方應用。
客戶端模式
這種方式是最簡單的方式，同時它也是最不安全的方式。只要客戶端發起請求，授權服務器即授予令牌。因此我們必須保證客戶端的安全性，所以這種方式一般應用於企業內部的服務器、服務之間，它們之間無用戶參與。
通過對四種工作模式的介紹，想必你已經明白了它們之間的區別，同時你也知道了它們具體的應用場景。最後我們將模式的選擇總結如下圖示：
參照如上選擇流程選擇對應的應用模式，相信你已經掌握瞭如何選擇合適的模式。