記一次開放平臺

百度百科是這樣定義開放平臺：

     開放平臺（Open Platform） 在軟件行業和網絡中，開放平臺是指軟件系統經過公開其應用程序編程接口（API）或函數（function)來使外部的程序能夠增長該軟件系統的功能或使用該軟件系統的資源，而不須要更改該軟件系統的源代碼。

在互聯網時代，把網站的服務封裝成一系列計算機易識別的數據接口開放出去，供第三方開發者使用，這種行爲就叫作Open API，提供開放API的平臺自己就被稱爲開放平臺。經過開放平臺，網站不只能提供對Web網頁的簡單訪問，還能夠進行復雜的數據交互，將它們的Web網站轉換爲與操做系統等價的開發平臺。第三方開發者能夠基於這些已經存在的、公開的Web網站而開發豐富多彩的應用。其次，開放平臺包含多種含義，這些不一一贅述，筆者主要是圍繞筆者在第一次參與開放平臺開發到第一個上線版本的過程，其餘相關的理論知識請自行腦補。

筆者接到的需求是：使用oauth2.0協議完成開放平臺的搭建，形如微信。

那麼什麼是oauth2.0協議呢？

一、OAuth（Open Authorization，開放受權）是爲用戶資源的受權定義了一個安全、開放及簡單的標準，第三方無需知道用戶的帳號及密碼，就可獲取到用戶的受權信息，而且這是安全的。

二、OAuth2.0是OAuth的最新版本

三、https://oauth.net/2/

                                 

兩眼一抹黑，在公司內部技術分享會有對其作過介紹，可是當時卻沒有投入相應時間去研究與琢磨，致使浪費多數時間在學習oauth2.0協議，實屬不應。

要說目前網絡上的博客做者能把oauth2.0講得最人性化，最通俗易懂，當屬阮一峯老師。阮老師的博客中將oauth2.0協議講的很是通俗易懂，關鍵是講得也很透徹，因此全部初學者都從阮老師的博客中入門。傳送門點此處。

oauth2.0協議中多個受權模式：

• 受權碼模式（authorization code）
• 簡化模式（implicit）
• 密碼模式（resource owner password credentials）
• 客戶端模式（client credentials）

四個模式各有優缺點，都有本身適合的場景，在此不一一贅述，可是筆者最終仍是選擇採用受權碼模式來作，由於它功能最完整、流程最嚴密，而且筆者以前簡單對接過微信的開發平臺，受權流程多采用該模式，因此想來它必定會更合適（後邊即使採用其餘的模式也能夠切換自如）。

筆者接到的第二個需求是：尋找合適的受權框架。

由於筆者所在公司很早就已經開始研究微服務，而且技術上也已經落地了一整套微服務架構，目前處於持續拆分服務階段，因此毫無疑問，若是在框架上作選擇，爲了與spring cloud微服務架構完美契合，最佳理想的選擇恐怕是spring security這個框架。從官方文檔介紹來看，它確實與spring cloud完美結合，而相比較其餘框架，好比apache 的shiro框架其實也能夠接入，而且它的接入成本也不會很高，可是從整個技術生態圈來講，不合適。

然而接入spring security的成本恐怕不低，由於spring security自己很是重，由於它自己就是一套很是完善的安全框架，除了受權以外，還有諸如服務於權限控制等功能模塊，而筆者手頭上的項目是本身實現的受權框架，並不須要權限控制等功能模塊，若是投入時間將原先的權限框架進行改造，徹底採用spring security來作，成本無疑是公司不能接受的。

思來想去，毫無頭緒，沒有一個合適的框架能夠完美解決眼下趕上的問題，該如何是好【其實投入了不少時間在研究spring security框架，可是從架構上並不符合咱們的當前的技術生態（也許沒有找到合適的方案），主要問題在於咱們的api-gateway的實現迥異】無奈之下，硬着頭皮去請教個人頂頭上司，尋求一個較好的解決方案。

上司的原話以下：

咱們目前的項目之因此很差採用spring security的緣由，無非是咱們最開始就沒有使用它來解決軟件的安全問題，因此接入成本很大，既然如此，那就本身實現一套ouath2.0的協議，不難處理，初版本先把受權碼模式實現出來能夠投入使用，後續版本迭代再把其餘受權模式實現起來便可。

糾結了一會最後仍是正式投入時間來研究開發oauth2.0協議，自己對於協議理解只能算入門，幸好有阮一峯老師的博客。

先理解相關的名詞定義：

Resource Owner：資源全部者，即用戶

Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，能夠是同一臺服務器，也能夠是不一樣的服務器。

Client：第三方應用程序

Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器

             

oauth2.0的受權協議流程大體以下：

（A）用戶打開客戶端之後，客戶端要求用戶給予受權。

（B）用戶贊成給予客戶端受權。

（C）客戶端使用上一步得到的受權，向認證服務器申請令牌。

（D）認證服務器對客戶端進行認證之後，確認無誤，贊成發放令牌。

（E）客戶端使用令牌，向資源服務器申請獲取資源。

（F）資源服務器確認令牌無誤，贊成向客戶端開放資源。

受權碼模式認證流程以下：

（A）用戶訪問客戶端，後者將前者導向認證服務器。

（B）用戶選擇是否給予客戶端受權。

（C）假設用戶給予受權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個受權碼。

（D）客戶端收到受權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的後臺的服務器上完成的，對用戶不可見。

（E）認證服務器覈對了受權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。

使用通俗的說法能夠理解爲：用戶須要訪問系統資源，此時應當檢查用戶是否有可用（沒有或者過時）令牌（access token）,若是沒有可用令牌，則向資源服務發起受權服務（從筆者的項目來講，既是外部應用請求認證服務器發起受權請求）。這個時候須要認證用戶是否授信（即要求用戶登陸系統，好比經過app打開登陸），登陸以後跳轉至是否受權頁面，該頁面須要展現的內容有：受權用戶協議，以及用戶受權的資源（好比用戶受權獲取用戶暱稱，手機號等資源）等相關信息。用戶確認受權以後，認證服務器發送受權碼（code），此時客戶端的服務端拿到受權碼向認證服務器申請令牌。認證服務器發放令牌，客戶端服務器獲取令牌後向資源服務器申請開放資源，資源服務器校驗令牌合法性後決定是否發放資源。

筆者在實現第一個版本的簡陋開放平臺趕上的幾個問題整理以下：

A、受權相關接口。

    一、發起受權接口：authorize

    二、確認受權接口：confirm_access

    三、換取token/刷新token接口：access_token

    四、校驗token：check_token

接口的實現不會複雜，spring security也就經過這種方式實現，內置的幾個受權相關接口，相關的代碼設計能夠優先參考spring security簡單實現。spring security經過filter作了不少事，可是隻須要提早出受權相關的模塊。

B、受權資源

用戶進入受權頁面須要肯定須要授予那些資源給到客戶端來請求，這個確定會跟隨不一樣的業務作不一樣的設計了。不過大體上是採用一種設計：接口即爲資源，設計好資源組。

資源是受權雙方都須要很是謹慎的一個問題，用戶謹慎受權，資源服務器謹慎開放資源，保證整個過程的合法以及安全。其次，將資源分配安排好，對後期的維護以及擴展都將很是友好。好比資源是對特定的接入方開放特定的數據權限，或者統一開放可開放的數據權限等等。

C、應用接口設計 

主要考慮做爲第三方接入，如何讓他們快速接入咱們的應用，爲咱們帶來價值。若是一套設計很是 不合理的接口將會形成對方接入混亂，成本高，難以維護等各類問題。一套好的設計方案，雙方都很是爽，接入方能夠快速接入，而且極易維護，豈不快哉？目前從市面上瞭解得開放平臺api設計大多爲如下兩類：

一、裸露的api接口：好比微信的公衆號開放，翻開微信公衆號的開放平臺文檔能夠看到他們羅列的一堆的接口列表。每一個接口都提供了很是的demo，調用以及調試都很是簡單，因此接入成本不高。

二、接口統一：好比淘寶的開放平臺，對外是統一的api地址，經過參數method做爲api名稱。淘寶的開放提供了很是友好的SDK集成，因此集成快速，而且成本會更低。

兩邊的接口設計各有優缺點。很差說那種更優。可是就目前我的喜愛來講，筆者傾向喜歡淘寶這種api設計風格，調用目標很是清晰，做爲接入方，只須要維護一個method列表，而不是一個接口列表，總以爲接口列表維護會更費勁一些，並且若是提供相應的SDK可讓接入更加方便快捷。

D、token生命週期管理

最合適的應該是經過redis的定時過時，不過這裏涉及了幾種狀況來討論（站在對方接入的角度來討論）

    一、token永不過時，這種設計其實不是很好，即用戶受權一次即可永久使用。網關中心最好對其作白名單控制。

    二、token過時時間很是常，1個月至一年，這種token其實不太適合將其放在redis上，由於這個token存在時間太長了，維護成本過高了，況且接入方的使用率不見得很高。

    三、token過時時間很是短，通常爲幾個小時至幾天，該token徹底能夠交給redis來管理。

    四、此處省略……

基於接入方可能會使用以上幾種情形來考慮該如何設計token過時時間會略微合適一點。

E、接口文檔

好的接口文檔一目瞭然。有些接口文檔一整套都本身實現，很是辛苦，有些則經過第三方插件直接生成，這種方式比較理想，好比Swagger文檔。

F、錯誤碼

這是很是關鍵的一套接入方與被接入方之間通訊的信息。接入方經過提供的錯誤碼能夠很是快速的定位問題並解決問題，因此一套優良的錯誤設計也是至關重要的。