在做接口測試時，經(jīng)常會碰到請求參數(shù)為token的類型，但是可能大部分測試人員對token，cookie，session的區(qū)別還是一知半解。

Cookie

cookie 是一個非常具體的東西，指的就是瀏覽器里面能永久存儲的一種數(shù)據(jù)，僅僅是瀏覽器實現(xiàn)的一種數(shù)據(jù)存儲功能。

cookie由服務器生成，發(fā)送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時會把該cookie發(fā)送給服務器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據(jù)太多磁盤空間，所以每個域的cookie數(shù)量是有限的。

Session

session 從字面上講，就是會話。這個就類似于你和一個人交談，你怎么知道當前和你交談的是張三而不是李四呢?對方肯定有某種特征(長相等)表明他就是張三。

session 也是類似的道理，服務器要知道當前發(fā)請求給自己的是誰。為了做這種區(qū)分，服務器就要給每個客戶端分配不同的“身份標識”，然后客戶端每次向服務器發(fā)請求的時候，都帶上這個“身份標識”，服務器就知道這個請求來自于誰了。至于客戶端怎么保存這個“身份標識”，可以有很多種方式，對于瀏覽器客戶端，大家都默認采用 cookie 的方式。

服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候session會丟失。

Token

Token的引入：Token是在客戶端頻繁向服務端請求數(shù)據(jù)，服務端頻繁的去數(shù)據(jù)庫查詢用戶名和密碼并進行對比，判斷用戶名和密碼正確與否，并作出相應提示，在這樣的背景下，Token便應運而生。

Token的定義：Token是服務端生成的一串字符串，以作客戶端進行請求的一個令牌，當?shù)谝淮蔚卿浐螅掌魃梢粋€Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數(shù)據(jù)即可，無需再次帶上用戶名和密碼。最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進制字符串，可以防止惡意第三方拼接token請求服務器)。

使用Token的目的：Token的目的是為了減輕服務器的壓力，減少頻繁的查詢數(shù)據(jù)庫，使服務器更加健壯。

傳統(tǒng)身份驗證

HTTP 是一種沒有狀態(tài)的協(xié)議，也就是它并不知道是誰是訪問應用。這里我們把用戶看成是客戶端，客戶端使用用戶名還有密碼通過了身份驗證，不過下回這個客戶端再發(fā)送請求時候，還得再驗證一下。

解決的方法就是，當用戶請求登錄的時候，如果沒有問題，我們在服務端生成一條記錄，這個記錄里可以說明一下登錄的用戶是誰，然后把這條記錄的 ID 號發(fā)送給客戶端，客戶端收到以后把這個 ID 號存儲在 Cookie 里，下次這個用戶再向服務端發(fā)送請求的時候，可以帶著這個 Cookie ，這樣服務端會驗證一個這個 Cookie 里的信息，看看能不能在服務端這里找到對應的記錄，如果可以，說明用戶已經(jīng)通過了身份驗證，就把用戶請求的數(shù)據(jù)返回給客戶端。

上面說的就是 Session，我們需要在服務端存儲為登錄的用戶生成的 Session ，這些 Session 可能會存儲在內(nèi)存，磁盤，或者數(shù)據(jù)庫里。我們可能需要在服務端定期的去清理過期的 Session 。

基于 Token 的身份驗證

使用基于 Token 的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。大概的流程是這樣的：

• 客戶端使用用戶名跟密碼請求登錄
• 服務端收到請求，去驗證用戶名與密碼
• 驗證成功后，服務端會簽發(fā)一個 Token，再把這個 Token 發(fā)送給客戶端
• 客戶端收到 Token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里
• 客戶端每次向服務端請求資源的時候需要帶著服務端簽發(fā)的 Token
• 服務端收到請求，然后去驗證客戶端請求里面帶著的 Token，如果驗證成功，就向客戶端返回請求的數(shù)據(jù)

APP登錄的時候發(fā)送加密的用戶名和密碼到服務器，服務器驗證用戶名和密碼，如果成功，以某種方式比如隨機生成32位的字符串作為token，存儲到服務器中，并返回token到APP，以后APP請求時，凡是需要驗證的地方都要帶上該token，然后服務器端驗證token，成功返回所需要的結果，失敗返回錯誤信息，讓他重新登錄。其中服務器上token設置一個有效期，每次APP請求的時候都驗證token和有效期。

那么我的問題來了：

1.服務器上的token存儲到數(shù)據(jù)庫中，每次查詢會不會很費時。如果不存儲到數(shù)據(jù)庫，應該存儲到哪里呢。

2.客戶端得到的token肯定要加密存儲的，發(fā)送token的時候再解密。存儲到數(shù)據(jù)庫還是配置文件呢?

token是個易失數(shù)據(jù)，丟了無非讓用戶重新登錄一下，新浪微博動不動就讓我重新登錄，反正這事兒我是無所謂啦。

所以如果你覺得普通的數(shù)據(jù)庫表撐不住了，可以放到 MSSQL/MySQL 的內(nèi)存表里(不過據(jù)說mysql的內(nèi)存表性能提升有限)，可以放到 Memcache里(講真，這個是挺常見的策略)，可以放到redis里(我做過這樣的實現(xiàn))，甚至可以放到 OpenResty 的變量字典里(只要你有信心不爆內(nèi)存)。

token是個憑條，不過它比門票溫柔多了，門票丟了重新花錢買，token丟了重新操作下認證一個就可以了，因此token丟失的代價是可以忍受的——前提是你別丟太頻繁，要是讓用戶隔三差五就認證一次那就損失用戶體驗了。

基于這個出發(fā)點，如果你認為用數(shù)據(jù)庫來保持token查詢時間太長，會成為你系統(tǒng)的瓶頸或者隱患，可以放在內(nèi)存當中。

比如memcached、redis，KV方式很適合你對token查詢的需求。

這個不會太占內(nèi)存，比如你的token是32位字符串，要是你的用戶量在百萬級或者千萬級，那才多少內(nèi)存。

要是數(shù)據(jù)量真的大到單機內(nèi)存扛不住，或者覺得一宕機全丟風險大，只要這個token生成是足夠均勻的，高低位切一下分到不同機器上就行，內(nèi)存絕對不會是問題。

客戶端方面這個除非你有一個非常安全的辦法，比如操作系統(tǒng)提供的隱私數(shù)據(jù)存儲，那token肯定會存在泄露的問題。比如我拿到你的手機，把你的token拷出來，在過期之前就都可以以你的身份在別的地方登錄。

解決這個問題的一個簡單辦法

1、在存儲的時候把token進行對稱加密存儲，用時解開。

2、將請求URL、時間戳、token三者進行合并加鹽簽名，服務端校驗有效性。

這兩種辦法的出發(fā)點都是：竊取你存儲的數(shù)據(jù)較為容易，而反匯編你的程序hack你的加密解密和簽名算法是比較難的。然而其實說難也不難，所以終究是防君子不防小人的做法。話說加密存儲一個你要是被人扒開客戶端看也不會被噴明文存儲……

方法1它拿到存儲的密文解不開、方法2它不知道你的簽名算法和鹽，兩者可以結合食用。

但是如果token被人拷走，他自然也能植入到自己的手機里面，那到時候他的手機也可以以你的身份來用著，這你就瞎了。

于是可以提供一個讓用戶可以主動expire一個過去的token類似的機制，在被盜的時候能遠程止損。

在網(wǎng)絡層面上token明文傳輸?shù)脑挄浅５奈ｋU，所以建議一定要使用HTTPS，并且把token放在post body里。

補充：

cookie與session的區(qū)別

1、cookie數(shù)據(jù)存放在客戶端上，session數(shù)據(jù)放在服務器上。

2、cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙

考慮到安全應當使用session。

3、session會在一定時間內(nèi)保存在服務器上。當訪問增多，會比較占用你服務器的性能

考慮到減輕服務器性能方面，應當使用COOKIE。

4、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。

5、所以個人建議：

將登陸信息等重要信息存放為SESSION

其他信息如果需要保留，可以放在COOKIE中

session與token的區(qū)別

session 和 oauth token并不矛盾，作為身份認證 token安全性比session好，因為每個請求都有簽名還能防止監(jiān)聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現(xiàn)有狀態(tài)的會話，仍然可以增加session來在服務器端保存一些狀態(tài)

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來保存session,因此用session token來標示自己就夠了，session/state由api server的邏輯處理。 如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session.可以在app里嵌入webkit,用一個隱藏的browser來管理cookie session.

Session 是一種HTTP存儲機制，目的是為無狀態(tài)的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 信息存儲到Session 里，因為SID 的不可預測性，暫且認為是安全的。這是一種認證手段。 而Token ，如果指的是OAuth Token 或類似的機制的話，提供的是 認證 和 授權 ，認證是針對用戶，授權是針對App 。其目的是讓 某App有權利訪問 某用戶 的信息。這里的 Token是唯一的。不可以轉(zhuǎn)移到其它 App上，也不可以轉(zhuǎn)到其它 用戶 上。 轉(zhuǎn)過來說Session 。Session只提供一種簡單的認證，即有此 SID，即認為有此 User的全部權利。是需要嚴格保密的，這個數(shù)據(jù)應該只保存在站方，不應該共享給其它網(wǎng)站或者第三方App。 所以簡單來說，如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用 API 接口，用 Token 。如果永遠只是自己的網(wǎng)站，自己的 App，用什么就無所謂了。

打破誤解：

“只要關閉瀏覽器 ，session就消失了?”

不對。對session來說，除非程序通知服務器刪除一個session，否則服務器會一直保留，程序一般都是在用戶做log off的時候發(fā)個指令去刪除session。

然而瀏覽器從來不會主動在關閉之前通知服務器它將要關閉，因此服務器根本不會有機會知道瀏覽器已經(jīng)關閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器后這個session id就消失了，再次連接服務器時也就無法找到原來的session。

如果服務器設置的cookie被保存在硬盤上，或者使用某種手段改寫瀏覽器發(fā)出的HTTP請求頭，把原來的session id發(fā)送給服務器，則再次打開瀏覽器仍然能夠打開原來的session.

恰恰是由于關閉瀏覽器不會導致session被刪除，迫使服務器為session設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就可以以為客戶端已經(jīng)停止了活動，才會把session刪除以節(jié)省存儲空間。

作者 | 王菜鳥1993

來源 | cnblogs.com/JamesWang1993/p/8593494.html