如果我通過抓包得到了api_token，user_token等等所有參數以及header，那在短時間內，我直接帶上我擷取到的參數，驗證規則一樣通過， 我不就可以用這個介面了？ 個人能想到的辦法就是把token驗證的時間弄短一點。 不知道大神們是怎麼解決這個問題的？
回複內容：
token就是起這個作用的啊……不就是為了讓你能用才設計的token麼。設計token的主要目的是不希望長時間儲存使用者的使用者名稱和密碼，所以轉換成一個隨機碼，這個碼本身就有替代使用者名稱和密碼的作用，所以一旦泄露了，自然後果也會很嚴重。
現在安全層級高的API一般都只能使用HTTPS，這樣從路徑中間是抓不到串連上的內容的，所以不會把token泄露給其他人。至於兩頭， 一頭本來就是使用者，一頭是你自己的伺服器，這個token本來就是應該在兩邊共用的內容吧。
以前有另一種設計是使用api_key和secret_key兩個值，其中api_key在HTTP當中明文傳輸，而secret_key不出現在HTTP明文中，而是作為MD5 Hash的一部分參與進來，一般將整個URL參數正規化（按參數名排序，統一轉換成小寫，正確進行URL編碼），然後加上secret_key，計算MD5，然後把MD5作為一個附加的sig參數通過HTTP傳遞，這樣即使中間抓到包，也只能看到api_key，看不到secret_key，就無法自由使用這個介面。但這個設計對於重放是有弱點的，雖然我不能自由地重新組合參數，但是我可以重新使用之前抓到的參數，這仍然是不安全的；而且，缺乏一個將secret_key安全分發到終端的手段。所以其實還是直接使用HTTPS比較有效。
作為參考我們來看一下OAuth 2.0的設計，OAuth 2.0是第三方登入，涉及到使用者、認證中心、第三方應用三方面的關係，它遇到的問題就要更複雜一些，我們可以看它如何擷取token，並且防止token被泄露給不應當泄露的一方：
- OAuth伺服器與第三方伺服器同時知道相同的api_key, secret_key
- 使用者與第三方伺服器同時知道api_key（通常是由第三方應用或者Web網頁攜帶的）
- 使用者與OAuth伺服器同時知道相同的使用者名稱密碼，第三方應用不知道
- 使用者申請第三方登入時，使用api_key調用OAuth伺服器登入介面（一般由第三方應用引導），使用OAuth伺服器的頁面輸入使用者名稱密碼，OAuth伺服器返回auth_code，這可以看作一個臨時的token。這一步必須使用https，保證使用者名稱和密碼不被竊取。
- 使用者使用auth_code調用第三方應用的介面（通常由callback機制自動完成），這一步可以使用HTTP，所以auth_code可能會泄露
- 第三方應用使用auth_code + api_key + secret_key調用OAuth伺服器的第二步登入介面，擷取access_token，也就是正式的token。雖然auth_code可能泄露，但是由於secret_key攻擊者無法獲得，也就無法利用auth_code來換取token。這一步必須使用HTTPS，保證secret_key不泄露。
至此，第三方應用成功擷取到了access_token，而這個access_token只在OAuth伺服器和第三方伺服器之間共用，不會泄露給包括使用者在內的第三方。可見這個過程中主要是依賴HTTPS的加密特性來保證最重要資料（使用者名稱、密碼、secret_key）不被泄露。此外，不同安全層級的token應該有不同的逾時時間，比如auth_code逾時時間非常短，而access_token有相對長的逾時時間。
介面用https， 抓包都是亂碼。但是也有偽裝中間人的方法？謝邀……
最極端的辦法：
每個token只一次有效……
當然，這涉及到大量的讀寫操作。
SO……一般不這麼搞……隨機數加token加時間戳記進行md5簽名 把簽名和隨機數 時間戳記一起傳給伺服器不是這樣子的，在伺服器端先要判斷session，通過之後才會進入到我們寫的token驗證中。1:https；
2:認證模組獨立，token入session，再次校正，這個和認證的設計有關係；
3:高頻率更換token，具體看業務重要性；
以上個人看法，可能不太嚴謹
