在做介面測試時，經常會碰到請求引數為token的型別，但是可能大部分測試人員對token，cookie，session的區別還是一知半解。
cookie:
cookie 是乙個非常具體的東西，指的就是瀏覽器裡面能永久儲存的一種資料，僅僅是瀏覽器實現的一種資料儲存功能。
cookie由伺服器生成，傳送給瀏覽器，瀏覽器把cookie以kv形式儲存到某個目錄下的文字檔案內，下一次請求同一**時會把該cookie傳送給伺服器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁碟空間，所以每個域的cookie數量是有限的。
session:
session 從字面上講，就是會話。這個就類似於你和乙個人交談，你怎麼知道當前和你交談的是張三而不是李四呢？對方肯定有某種特徵（長相等）表明他就是張三。
session 也是類似的道理，伺服器要知道當前發請求給自己的是誰。為了做這種區分，伺服器就要給每個客戶端分配不同的「身份標識」，然後客戶端每次向伺服器發請求的時候，都帶上這個「身份標識」，伺服器就知道這個請求來自於誰了。至於客戶端怎麼儲存這個「身份標識」，可以有很多種方式，對於瀏覽器客戶端，大家都預設採用 cookie 的方式。
伺服器使用session把使用者的資訊臨時儲存在了伺服器上，使用者離開**後session會被銷毀。這種使用者資訊儲存方式相對cookie來說更安全，可是session有乙個缺陷：如果web伺服器做了負載均衡，那麼下乙個操作請求到了另一台伺服器的時候session會丟失。
token:
token的引入：token是在客戶端頻繁向服務端請求資料，服務端頻繁的去資料庫查詢使用者名稱和密碼並進行對比，判斷使用者名稱和密碼正確與否，並作出相應提示，在這樣的背景下，token便應運而生。
token的定義：token是服務端生成的一串字串，以作客戶端進行請求的乙個令牌，當第一次登入後，伺服器生成乙個token便將此token返回給客戶端，以後客戶端只需帶上這個token前來請求資料即可，無需再次帶上使用者名稱和密碼。最簡單的token組成:uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進製制字串，可以防止惡意第三方拼接token請求伺服器)。
使用token的目的：token的目的是為了減輕伺服器的壓力，減少頻繁的查詢資料庫，使伺服器更加健壯。
傳統身份驗證:
http 是一種沒有狀態的協議，也就是它並不知道是誰是訪問應用。這裡我們把使用者看成是客戶端，客戶端使用使用者名稱還有密碼通過了身份驗證，不過下回這個客戶端再傳送請求時候，還得再驗證一下。
解決的方法就是，當使用者請求登入的時候，如果沒有問題，我們在服務端生成一條記錄，這個記錄裡可以說明一下登入的使用者是誰，然後把這條記錄的 id 號傳送給客戶端，客戶端收到以後把這個 id 號儲存在 cookie 裡，下次這個使用者再向服務端傳送請求的時候，可以帶著這個 cookie ，這樣服務端會驗證乙個這個 cookie 裡的資訊，看看能不能在服務端這裡找到對應的記錄，如果可以，說明使用者已經通過了身份驗證，就把使用者請求的資料返回給客戶端。
上面說的就是 session，我們需要在服務端儲存為登入的使用者生成的 session ，這些 session 可能會儲存在記憶體，磁碟，或者資料庫裡。我們可能需要在服務端定期的去清理過期的 session 。
基於 token 的身份驗證:
使用基於 token 的身份驗證方法，在服務端不需要儲存使用者的登入記錄。大概的流程是這樣的：
那麼我的問題來了： 1.伺服器上的token儲存到資料庫中，每次查詢會不會很費時。如果不儲存到資料庫，應該儲存到**呢。 2.客戶端得到的token肯定要加密儲存的，傳送token的時候再解密。儲存到資料庫還是配置檔案呢？
token是個憑條，不過它比門票溫柔多了，門票丟了重新花錢買，token丟了重新操作下認證乙個就可以了，因此token丟失的代價是可以忍受的——前提是你別丟太頻繁，要是讓使用者隔三差五就認證一次那就損失使用者體驗了。
基於這個出發點，如果你認為用資料庫來保持token查詢時間太長，會成為你系統的瓶頸或者隱患，可以放在記憶體當中。
比如memcached、redis，kv方式很適合你對token查詢的需求。
這個不會太佔記憶體，比如你的token是32位字串，要是你的使用者量在百萬級或者千萬級，那才多少記憶體。
要是資料量真的大到單機記憶體扛不住，或者覺得一宕機全丟風險大，只要這個token生成是足夠均勻的，高低位切一下分到不同機器上就行，記憶體絕對不會是問題。
客戶端方面這個除非你有乙個非常安全的辦法，比如作業系統提供的隱私資料儲存，那token肯定會存在洩露的問題。比如我拿到你的手機，把你的token拷出來，在過期之前就都可以以你的身份在別的地方登入。
解決這個問題的乙個簡單辦法
1、在儲存的時候把token進行對稱加密儲存，用時解開。
2、將請求url、時間戳、token三者進行合併加鹽簽名，服務端校驗有效性。
這兩種辦法的出發點都是：竊取你儲存的資料較為容易，而反彙編你的程式hack你的加密解密和簽名演算法是比較難的。然而其實說難也不難，所以終究是防君子不防小人的做法。話說加密儲存乙個你要是被人扒開客戶端看也不會被噴明文儲存……
方法1它拿到儲存的密文解不開、方法2它不知道你的簽名演算法和鹽，兩者可以結合食用。
但是如果token被人拷走，他自然也能植入到自己的手機裡面，那到時候他的手機也可以以你的身份來用著，這你就瞎了。
於是可以提供乙個讓使用者可以主動expire乙個過去的token類似的機制，在被盜的時候能遠端止損。
在網路層面上token明文傳輸的話會非常的危險，所以建議一定要使用https，並且把token放在post body裡。
補充：
cookie與session的區別:
1、cookie資料存放在客戶端上，session資料放在伺服器上。
2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙
考慮到安全應當使用session。
3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較占用你伺服器的效能
考慮到減輕伺服器效能方面，應當使用cookie。
4、單個cookie儲存的資料不能超過4k，很多瀏覽器都限制乙個站點最多儲存20個cookie。
5、所以個人建議：
將登陸資訊等重要資訊存放為session
其他資訊如果需要保留，可以放在cookie中
session與token的區別:
session 和 oauth token並不矛盾，作為身份認證 token安全性比session好，因為每個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現有狀態的會話，仍然可以增加session來在伺服器端儲存一些狀態
打破誤解:
「只要關閉瀏覽器 ，session就消失了？」
不對。對session來說，除非程式通知伺服器刪除乙個session，否則伺服器會一直保留，程式一般都是在使用者做log off的時候發個指令去刪除session。
然而瀏覽器從來不會主動在關閉之前通知伺服器它將要關閉，因此伺服器根本不會有機會知道瀏覽器已經關閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來儲存session id，而關閉瀏覽器後這個session id就消失了，再次連線伺服器時也就無法找到原來的session。如果伺服器設定的cookie被儲存在硬碟上，或者使用某種手段改寫瀏覽器發出的http請求頭，把原來的session id傳送給伺服器，則再次開啟瀏覽器仍然能夠開啟原來的session.
恰恰是由於關閉瀏覽器不會導致session被刪除，迫使伺服器為session設定了乙個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，伺服器就可以以為客戶端已經停止了活動，才會把session刪除以節省儲存空間。
本文轉至
介面鑑權之cookie session和token
一 鑑權 二 引入cookie session和token的原因 目前，大部分介面使用的都是http協議，而http協議是無狀態的，即本次請求和上一次請求是沒有任何關係的，無法共享資訊。比如，像我們現在 下單需要先登入，你登入成功了之後再去下單，伺服器怎麼知道你是已登入狀態呢？三 cookie和se...
Cookie session和token的區別
cookie的內容是儲存一小段文字資訊，這些文字資訊組成乙份通行證。它是客戶端對於無狀態協議的一種解決方案。cookie的原理 1 客戶端第一次請求時，傳送資料到伺服器。2 伺服器返回響應資訊的同時，還會傳回乙個cookie cookie s 001 3 客戶端接收伺服器的響應之後，瀏覽器會將coo...
cookie session和token的區別
cookie cookie由伺服器生成，儲存在客戶端瀏覽器，是乙個檔案。容量小，單個cookie儲存的資料不能超過4k 容易被劫持，不安全 可以被使用者禁止 session session儲存在伺服器端，沒有資料量限制 session可以放在檔案 資料庫 記憶體等中 session大多數都是用coo...