前兩篇詳細介紹了OAuth 2.0中的兩個核心服務器，現在只剩下最后一個受保護資源服務器了，它可以說是OAuth 2.0的終極目的，前面做了那么多，最終就是為了去受保護資源服務器上獲取用戶想要的數據，與前兩者一樣，受保護資源服務器也有它要完成的使命：
如上圖所示，它需要完成：
- 解析令牌
- 校驗令牌
- 不同場景下提供不同的服務
一句話概括，資源服務器需要做的就是從傳入的HTTP請求中解析出OAuth令牌，驗證該令牌，並確定它能用於哪些請求！
一、解析令牌
前一篇文章【https://www.cnblogs.com/hellowhy/p/15521724.html】中提到發送令牌參數的方式有三種：
- 使用HTTP Authorization頭部；
- 使用表單格式的請求體參數
- 使用URL編碼的查詢參數
但是一般情況下都是優先選擇header方式，為了更好的兼容不同的客戶端，資源服務器上最好提供三種不同傳遞方式的解析
OAuth bearer令牌使用規范規定，在使用HTTP Authorization頭部傳送令牌時，HTTP頭部的值以關鍵字Bearer開頭，后跟一個空格，再跟令牌值本身。而且，OAuth規范還規定 Bearer關鍵字不區分大小寫。此外還規定了Authorization頭部關鍵字本身不區分大小寫，這意味着以下所欲HTTP頭部都是等價的：
- Authorization: Bearer 8989jksihtbnpsoit7hsj
- Authorization: bearer 8989jksihtbnpsoit7hsj
- authorization: BEARER 8989jksihtbnpsoit7hsj
注意：令牌值本身是區分大小寫的！！！
當資源服務器接收到請求后，需要兼容對三種請求方式的解析：
首先，從Authorization請求頭中獲取令牌，即bearer 之后的部分，如果獲取到則不進行其他方式的獲取
其次，當從header中獲取不到時，嘗試從表單請求參數中獲取。（不推薦，因為這種方式限制了APi的輸入只能是表單形式）
最后，如果前兩者都沒有獲取到，則嘗試從查詢參數中獲取
當通過三種方式都沒有獲取到時，證明客戶端請求參數有問題，直接返回錯誤信息，否則進行下一步校驗令牌。
二、校驗令牌
令牌是由授權服務器的令牌端點頒發，可以存儲在共享數據庫中，資源服務器需要根據請求中的令牌值查詢令牌是否存在，在存在的情況下校驗令牌是否有效，如果校驗失敗則直接返回錯誤信息給客戶端！
雖然使用共享數據庫是一種非常常見的OAuth部署模式，但它絕對不是唯一選擇。有一個叫做令牌內省（token introspection）的Web協議，它可以由授權服務器提供接口，讓資源服務器能夠在運行時檢查令牌的狀態。這使得資源服務器可以像客戶端那樣將令牌本身視為不透明的，代價是使用更多的網絡流量。還要另一種方式：可以在令牌內包含受保護資源能夠直接解析並理解的信息。JWT就是這樣一種數據結構，它可以使用受加保護的JSON對象攜帶聲明信息。
在實際的應用過程中，訪問資源服務器的每一個接口都需要校驗令牌，為了不在每個方法中都進行校驗，一般都是將校驗token的邏輯寫在攔截器中進行。
三、提供服務
在很多的API設計中，不同的操作需要不同的訪問權限，還有一些API會根據授權者不同而返回不同的結果，或者根據不同權限返回某一部分信息，一般有以下三種場景。
3.1 不同權限范圍對應不同的操作
在這種風格的API設計中，不同類型的操作需要不同的權限范圍，才能調用成功。這使得資源服務器可以根據客戶端能執行的操作來划分功能，這也是在單個授權服務器對應的多個資源服務器之間使用單個訪問令牌的常用方法。
舉個例子🌰 假設客戶端A注冊時的授權范圍是通過對接口的操作方式區分的，有write、read、delete三種操作權限，當它請求授權時，資源擁有者只授予read權限給它，當它獲取到訪問令牌之后，向資源服務器發起請求，這時它所能請求的只有GET類型的方法，如果請求POST或DELETE，資源服務器直接拒絕！
在任何情況下，即使令牌有效，但只要權限范圍不正確，同樣返回錯誤！！！
3.2 不同權限范圍對應不同的數據結果
在這種風格的API設計中，同一個處理函數可以根據傳入的令牌中包含的權限范圍不同，而返回不同類別的信息。如果數據結構復雜，且希望通過同一個API端點為客戶端提供多種信息子集的訪問，這樣的設計就非常有用！
舉個例子🌰 假設客戶端B注冊時的授權范圍是通過數據類型區分的，有企業、用戶兩種數據權限，當它請求授權時，資源擁有者只授予企業權限給它，那么當它獲取到訪問令牌之后，只能請求企業類型的資源，而不能請求用戶類型的資源，因為資源服務器校驗令牌時能查到該令牌對應的權限只有企業，如果用戶請求了獲取用戶或者企業和用戶的接口，就會報錯！
3.3 不同的用戶對應不同的數據結果
在這種風格的API設計中，同一個處理函數可以根據授權客戶端的用戶不同而返回不同的信息。這是一種常見的API設計模式，它使得客戶端應用在不知道用戶是誰的情況下，調用同一個URL也能獲取個性化的結果。
舉個例子🌰 假設客戶端C注冊時的授權范圍有管理員、普通用戶兩種用戶，當它向一個管理員角色的資源擁有者請求授權時，該管理員只授予它普通用戶的權限，那么當它獲取到訪問令牌之后，只能請求普通用戶有權訪問的資源，如果訪問管理員能訪問的資源，則資源服務器會根據資源能被訪問的權限范圍對它進行拒絕！
使用OAuth能對受保護資源實現的訪問控制遠不止本文所列的這些，但是不管這樣，在任何情況下，資源服務器都對訪問令牌的含義擁有最終決定權，不管資源服務器外包了多少決策過程，最終都由它來決定如何處理給定請求！
四、總結
使用OAuth保護Web API 非常簡單：
- 從傳入的請求中解析令牌
- 通過授權服務驗證令牌
- 根據令牌的權限范圍做出響應，令牌的權限范圍多種多樣
至此，OAuth 2.0中的三巨頭梳理的已經差不多了，接下來會梳理一下OAuth 2.0中的其他許可類型，加油！！！