針對
--->非開放性平台
--->公司內部產品
介面特點彙總：
1、因為是非開放性的，所以所有的介面都是封閉的，只對公司內部的產品有效；
2、因為是非開放性的，所以oauth那套協議是行不通的，因為沒有中間使用者的授權過程；
3、有點介面需要使用者登入才能訪問；
4、有點介面不需要使用者登入就可訪問；
針對以上特點，移動端與服務端的通訊就需要2把鑰匙，即2個token。
第乙個token是針對介面的（api_token）；
第二個token是針對使用者的（user_token）；
先說第乙個token（api_token）
它的職責是保持介面訪問的隱蔽性和有效性，保證介面只能給自家人用，怎麼做到？參考思路如下：
按伺服器端和客戶端都擁有的共同屬性生成乙個隨機串，客戶端生成這個串，伺服器也按同樣演算法生成乙個串，用來校驗客戶端的串。
現在的介面基本是mvc模式，url基本是restful風格，url大體格式如下：
模組名/控制器名/方法名?引數名1=引數值1&引數名2=引數值2&引數名3=引數值3
介面token生成規則參考如下：
api_token = md5 ('模組名' + '控制器名' + '方法名' + '2013-12-18' + '加密金鑰') = 770fed4ca2aabd20ae9a5dd774711de2
其中的
1、 '2013-12-18' 為當天時間，
2、'加密金鑰' 為私有的加密金鑰，手機端需要在服務端註冊乙個「介面使用者」賬號後，系統會分配乙個賬號及密碼，資料表設計參考如下：
欄位名 字段型別 注釋
client_id varchar(20) 客戶端id
client_secret varchar(20) 客戶端(加密)金鑰
（注：只列出了核心字段，其它的再擴充套件吧！！！）
再說第二個token（user_token）
它的職責是保護使用者的使用者名稱及密碼多次提交，以防密碼洩露。
如果介面需要使用者登入，其訪問流程如下：
1、使用者提交「使用者名稱」和「密碼」，實現登入（條件允許，這一步最好走https）；
2、登入成功後，服務端返回乙個 user_token，生成規則參考如下：
user_token = md5('使用者的uid' + 'unix時間戳') = etye0fgkgk4ca2aabd20ae9a5dd77471fgf
服務端用資料表維護user_token的狀態，表設計如下：
欄位名 字段型別 注釋
user_id int 使用者id
user_token varchar(36) 使用者token
expire_time int 過期時間（unix時間戳）
（注：只列出了核心字段，其它的再擴充套件吧！！！）
服務端生成 user_token 後，返回給客戶端（自己儲存），客戶端每次介面請求時，如果介面需要使用者登入才能訪問，則需要把 user_id 與 user_token 傳回給服務端，服務端接受到這2個引數後，需要做以下幾步：
1、檢測 api_token的有效性；
2、刪除過期的 user_token 表記錄；
3、根據 user_id，user_token 獲取表記錄，如果表記錄不存在，直接返回錯誤，如果記錄存在，則進行下一步；
4、更新 user_token 的過期時間（延期，保證其有效期內連續操作不掉線）；
5、返回介面資料；
介面用例如下：
1、發布日誌
url： blog/index/addblog?client_id=wt3734wy636dhd3636sr5858t6&api_token=880fed4ca2aabd20ae9a5dd774711de2&user_token=etye0fgkgk4ca2aabd20ae9a5dd77471fgf&user_id=12
請求方式： post
post引數：title=我是標題&content=我是內容
返回資料：
對於 api_token 的校驗，其安全性還可再增強：
增強地方一：
介面表欄位名
字段型別
注釋api_id
int介面id
api_name
varchar(120)
介面名，以"/"作為分割線，如 blog/index/addblog
api_domain
varchar(256)
所屬領域
is_enabled
tinyint(1)
是否可用 1:可用 0:不可用
add_time
int新增時間（戳）
（注：只列出了核心字段，其它的再擴充套件吧！！！）
授權表欄位名
字段型別
注釋client_id
int客戶端id
api_id
intapi編號
api_name
varchar(120)
介面名，以"/"作為分割線，如 blog/index/addblog
is_enabled
tinyint(1)
是否可用 1:可用 0:不可用
add_time
int新增時間（戳）
expire_time
int過期時間（戳）
（注：只列出了核心字段，其它的再擴充套件吧！！！）
執行過程如下：
1、移動端與服務端生成的 api_token 進行對比，如果不相等，則直接返回錯誤，否則，進入下一步；
2、根據介面url，組裝 api_name，再加上客戶端傳回的 client_id 為引數，查詢 「授權表」記錄，如果記錄存在，且有效（是否可用，是否過期），則表示許可權驗證通過，返回介面資料，否則返回錯誤資訊；
增強地方二：
對於一些很特殊的介面，怎麼特殊，哪些算特殊，我也不知道，總而言之，就是感覺http請求有可能被劫取，傳遞引數有可能被竄改等情況，還是舉個例子來說吧：
有個直接轉賬介面，頁面上 我輸入的是5元，表示我要給對方某某轉賬5元，結果在http傳遞過程中，被人劫取並竄改成了 10000元，而且入賬物件改成了「黑客」的賬號，那不是虧大發了，思考了一下，應該有2種方案解決這個問題，
方案一：走https，這個就不多說，比較公認的安全機制；
方案二：走數字簽名，實現原理如下：
乙個http請求，假如需要傳遞如下3個引數
引數名1=引數值1
引數名2=引數值2
引數名3=引數值3
我們可以再追加乙個引數，該引數的名為 identity_key （名字是什麼不重要），該引數的值為 加密金鑰')
API介面安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
介面的安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
開放介面API安全性
開放介面時最基本需要考慮到介面不應該被別人隨意訪問，而我也不能隨意訪問到其他使用者的資料，從而保證使用者與使用者之間的資料隔離。這個時候我們就有必要引入token機制了。具體的做法 在使用者成功登入時，系統可以返回客戶端乙個token，後續客戶端呼叫服務端的介面，都需要帶上token，而服務端需要校...