1樓：靈劍
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有相對長的超時時間。
你怎麼理解「乙個好的服務端介面」
今天也要加油鴨 第乙個我是這樣設計的 查詢條件要前台自己傳，分頁，排序都是前台傳。後台根據條件和許可權，取資料，返回。過濾條件也是動態新增的，自動按照前台傳輸字段，匹配物件屬性 字段 生成條件 複雜點的定義乙個規範，在後台按規範分解再匹配 如時間範圍，模糊匹配等 這在web裡面，用到jqgrid控制...
GIT windows 搭建服務端的方法？
預子 用win10附帶的openssh伺服器就可以，寫了個教程在碼雲上https Eric Qiang 傻瓜方案 伺服器端 Gitblit 客戶端 Git for Windows 什麼SSH都直接就有了。一 兩個小時就玩轉。國內網上的小文章很多。 WSWS 推薦幾個我使用過後效果不錯的。如果你無需分...
SESSION在服務端（PHP JAVA）具體是如何實現的？
逃學小小生 php中 session 可以存在檔案裡,一般是這樣,所以有時候ajax輪詢比較密集的時候,session start 會失敗,會告訴你session檔案開啟失敗 session 可以存在記憶體裡,比如存在memcache裡面,memcache是常住記憶體的跟php沒啥關係 sessio...