根據使用者名稱或者使用者id，結合使用者的ip或者裝置號，生成乙個token。在請求後台，後台獲取http的head中的token，校驗是否合法（和資料庫或者redis中記錄的是否一致，在登入或者初始化的時候，存入資料庫/redis）
在使用base64方式的編碼後，token字串還是有20多位，有的時候還是嫌它長了。由於guid（也叫uuid）本身就有128bit，在要求有良好的可讀性的前提下，很難進一步改進了。那我們如何產生更短的字串呢？還有一種方式就是較少token的長度，不用guid，而採用一定長度的隨機數，例如64bit，再用base64編碼表示：
var rnd = new
random();
vartokendata =
userip+userid
;rnd.nextbytes(tokendata);
vartoken = convert.tobase64string(tokendata).trimend('=');
由於這裡只用了64bit，此時得到的字串為onh0h95n7nw的形式，長度要短一半。這樣就方便攜帶多了。但是這種方式是沒有唯一性保證的。不過用來作為身份認證的方式還是可以的（如網盤的提取碼）。
客戶端和伺服器都儲存乙個秘鑰，每次傳輸都加密，服務端根據秘鑰解密。
客戶端：
1、設定乙個key（和伺服器端相同）
2、根據上述key對請求進行某種加密（加密必須是可逆的，以便伺服器端解密）
3、傳送請求給伺服器
伺服器端：
1、設定乙個key
2、根據上述的key對請求進行解密（校驗成功就是「信任」的客戶端發來的資料，否則拒絕響應）
3、處理業務邏輯並產生結果
4、將結果反饋給客戶端
比如spring
security－oauth
有興趣的，可以參考這篇帖子
介面的安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
如何保證資料安全性？ 討論
1 是資料本身的安全。主要是指採用現代密碼演算法對資料進行主動保護，如資料保密 資料完整性 雙向強身份認證等 2 是資料防護的安全。主要是採用現代資訊儲存手段對資料進行主動防護，如通過磁碟陣列 資料備份 異地容災等手段保證資料的安全，資料安全是一種主動的包含措施，資料本身的安全必須基於可靠的加密演算...
測試人員如何保證業務安全性？
業務安全 某個平台上的業務是指該平台使用者在使用過程中涉及到的一系列流程，而業務安全就是保證這些流程按照預定的規則執行。下面先來看看常見的業務安全點 業務威脅 常見的業務安全點 由於網際網路企業的特性，其主要業務直接體現在其平台上。其中有不少通用的業務流程 a 註冊 b 登入 c 密碼找回 d 使用...