服務端提供各種功能接口供客戶端調用，那麼怎樣才能確保請求是來自合法的客戶端，而不是非法的請求呢？
ringa_lee
驗證token，或服務端用OAuth2框架
你是如何定義合法和非法的？在SSO框架下，有token就是橫著走，如果是第三方肯定需要appid和appsecret，需要授權的話還要帶上AccessToken，這樣也是橫著走，最簡單的是寫一個IP攔截器，只允許信任IP通過，但是是用於內部互相調用的高級別攔截了，一般來說對方提供了token或appsecret，基本上都算是合法的吧？
在設計API時，要確保RESTful API的安全性，主要考慮三個大面向：
1.對受限資源的登入授權2.對請求做身分認證3.加密資料
一、受限資源的登入授權此流程不是本文重點，不贅述，基本流程如下：
客戶端提交帳號資訊（使用者名稱+密碼）到服務端
服務端驗證成功，返回AccessToken給客戶端儲存3.存取受限資源時，客戶端帶入AccessToken就可存取。
二、請求認證如果不對請求進行簽名認證，那麼可以簡單的通過fiddler等工具輕易抓包拿到數據，並進行篡改，提交，大規模批量調用，則會使系統產生大量垃圾數據，系統資源被大量消耗，甚至無法正常使用（另說，當然可以透過GateWay進行限流），因而我們需要對請求進行簽名認證。
URL格式URL:schema://domain/path?query&imei×tamp&sign
參數說明簽章方法sign=signature(path?query&imei×tamp&SIGN_KEY)
驗證流程認證邏輯1、初始時，服務端存有各App版本的SIGN_KEY，客戶端存有對應版本的SIGN_KEY2、當要發送請求之前，透過簽章方法加密，得到一個sign3、發送請求的時候，連同sign一起傳送給伺服器端4、伺服器端先驗證時間戳timestamp是否有效，例如伺服器時間戳5分鐘之前的請求視為無效；5、然後取對應版本的SIGN_KEY驗證sign是否合法6、為了防止重播攻擊，需要檢查sign是否在redis中存儲，如不存在則存入redis（緩存5分鐘）
如何防止資料竄改這裡透過簽章參數中包含原有請求的所有參數，改動任意參數，sign值都會不同，因此無法竄改。
如何防止重播攻擊由於簽章演算法中還有imei(裝置唯一Id)、timestamp參數，且簽章演算法為不可逆演算法（如md5或sha1），因而對於正常的每個請求sign值不會重複。此時服務端可以儲存5分鐘的sign值，來做重播攻擊時的驗證過濾，超過5分鐘的請求則直接被timestamp校驗過濾。
總結如此便實現了請求認證，防止資料篡改，重播攻擊，但是需要確保App密鑰(SIGN_KEY)的安全保存，其優點是容易理解與實現，缺點是需要承擔安全保存密鑰和定期更新密鑰的負擔。
三、敏感據加密1)、部署SSL基礎設施（即HTTPS），敏感資料的傳輸全部基於SSL。 2)、僅對部分敏感資料做加密（例如帳號+密碼），並加入某種隨機數字作為加密鹽，以防範資料被竄改。
我們用的RSA加密演算法,請求資料的參數均轉成json然後用伺服器RSA憑證對json進行加密,http請求就可以了,服務端私鑰解密
使用oauth2或類似的token之類的
驗證token，或服務端用OAuth2框架
你是如何定義合法和非法的？在SSO框架下，有token就是橫著走，如果是第三方肯定需要appid和appsecret，需要授權的話還要帶上AccessToken，這樣也是橫著走，最簡單的是寫一個IP攔截器，只允許信任IP通過，但是是用於內部互相調用的高級別攔截了，一般來說對方提供了token或appsecret，基本上都算是合法的吧？
在設計API時，要確保RESTful API的安全性，主要考慮三個大面向：
一、受限資源的登入授權
此流程不是本文重點，不贅述，基本流程如下：
客戶端提交帳號資訊（使用者名稱+密碼）到服務端
服務端驗證成功，返回AccessToken給客戶端儲存
3.存取受限資源時，客戶端帶入AccessToken就可存取。
二、請求認證
如果不對請求進行簽名認證，那麼可以簡單的通過fiddler等工具輕易抓包拿到數據，並進行篡改，提交，大規模批量調用，則會使系統產生大量垃圾數據，系統資源被大量消耗，甚至無法正常使用（另說，當然可以透過GateWay進行限流），因而我們需要對請求進行簽名認證。
URL格式
URL:schema://domain/path?query&imei×tamp&sign
參數說明
簽章方法
sign=signature(path?query&imei×tamp&SIGN_KEY)
驗證流程
認證邏輯
1、初始時，服務端存有各App版本的SIGN_KEY，客戶端存有對應版本的SIGN_KEY
2、當要發送請求之前，透過簽章方法加密，得到一個sign
3、發送請求的時候，連同sign一起傳送給伺服器端
4、伺服器端先驗證時間戳timestamp是否有效，例如伺服器時間戳5分鐘之前的請求視為無效；
5、然後取對應版本的SIGN_KEY驗證sign是否合法
6、為了防止重播攻擊，需要檢查sign是否在redis中存儲，如不存在則存入redis（緩存5分鐘）
如何防止資料竄改
這裡透過簽章參數中包含原有請求的所有參數，改動任意參數，sign值都會不同，因此無法竄改。
如何防止重播攻擊
由於簽章演算法中還有imei(裝置唯一Id)、timestamp參數，且簽章演算法為不可逆演算法（如md5或sha1），因而對於正常的每個請求sign值不會重複。此時服務端可以儲存5分鐘的sign值，來做重播攻擊時的驗證過濾，超過5分鐘的請求則直接被timestamp校驗過濾。
總結
如此便實現了請求認證，防止資料篡改，重播攻擊，但是需要確保App密鑰(SIGN_KEY)的安全保存，其優點是容易理解與實現，缺點是需要承擔安全保存密鑰和定期更新密鑰的負擔。
三、敏感據加密
1)、部署SSL基礎設施（即HTTPS），敏感資料的傳輸全部基於SSL。
2)、僅對部分敏感資料做加密（例如帳號+密碼），並加入某種隨機數字作為加密鹽，以防範資料被竄改。
我們用的RSA加密演算法,請求資料的參數均轉成json然後用伺服器RSA憑證對json進行加密,http請求就可以了,服務端私鑰解密
使用oauth2或類似的token之類的