cookie、session、token區分

https://www.cnblogs.com/moyand/p/9047978.html

http://www.cnblogs.com/JamesWang1993/p/8593494.html

Cookie（保存在客戶端）

cookie 是一個很是具體的東西，指的就是瀏覽器裏面能永久存儲的一種數據，僅僅是瀏覽器實現的一種數據存儲功能。

cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。因爲cookie是存在客戶端上的，因此瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁盤空間，因此每一個域的cookie數量是有限的。

Session（保存在服務端）

session 從字面上講，就是會話。這個就相似於你和一我的交談，你怎麼知道當前和你交談的是張三而不是李四呢？對方確定有某種特徵（長相等）代表他就是張三。

session 也是相似的道理，服務器要知道當前發請求給本身的是誰。爲了作這種區分，服務器就要給每一個客戶端分配不一樣的「身份標識」，而後客戶端每次向服務器發請求的時候，都帶上這個「身份標識」，服務器就知道這個請求來自於誰了。至於客戶端怎麼保存這個「身份標識」，能夠有不少種方式，對於瀏覽器客戶端，你們都默認採用 cookie 的方式（將sessionid放置於cookie中）。

服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站後session會被銷燬。這種用戶信息存儲方式相對cookie來講更安全，但是session有一個缺陷：若是web服務器作了負載均衡，那麼下一個操做請求到了另外一臺服務器的時候session會丟失。

Token

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

Token的定義：Token是服務端生成的一串字符串，以做客戶端進行請求的一個令牌，當第一次登陸後，服務器生成一個Token便將此Token返回給客戶端，之後客戶端只需帶上這個Token前來請求數據便可，無需再次帶上用戶名和密碼。最簡單的token組成:uid(用戶惟一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成必定長的十六進制字符串，能夠防止惡意第三方拼接token請求服務器)。

使用Token的目的：Token的目的是爲了減輕服務器的壓力，減小頻繁的查詢數據庫，使服務器更加健壯。

基於Token的身份驗證的過程以下:

1.用戶經過用戶名和密碼發送請求。

2.程序驗證。

3.程序返回一個簽名的token 給客戶端。

4.客戶端儲存token,而且每次用於每次發送請求。

5.服務端驗證token並返回數據。

 每一次請求都須要token。token應該在HTTP的頭部發送從而保證了Http請求無狀態。咱們一樣經過設置服務器屬性Access-Control-Allow-Origin:* ，讓服務器能接受到來自全部域的請求。須要主要的是，在ACAO頭部標明(designating)*時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。

區別

cookie與session的區別

一、cookie數據存放在客戶端上，session數據放在服務器上。

二、cookie不是很安全，別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
   考慮到安全應當使用session。

三、session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
   考慮到減輕服務器性能方面，應當使用COOKIE。

四、單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。

五、因此我的建議：
   將登錄信息等重要信息存放爲SESSION
   其餘信息若是須要保留，能夠放在COOKIE中

 

session與token的區別

　　session 和 oauth token並不矛盾，做爲身份認證 token安全性比session好，由於每一個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通信安全了。如上所說，若是你須要實現有狀態的會話，仍然能夠增長session來在服務器端保存一些狀態

　　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存儲機制，目的是爲無狀態的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 信息存儲到Session 裏，由於SID 的不可預測性，暫且認爲是安全的。這是一種認證手段。 而Token ，若是指的是OAuth Token 或相似的機制的話，提供的是 認證 和 受權 ，認證是針對用戶，受權是針對App 。其目的是讓 某App有權利訪問 某用戶 的信息。這裏的 Token是惟一的。不能夠轉移到其它 App上，也不能夠轉到其它 用戶 上。 轉過來講Session 。Session只提供一種簡單的認證，即有此 SID，即認爲有此 User的所有權利。是須要嚴格保密的，這個數據應該只保存在站方，不該該共享給其它網站或者第三方App。 因此簡單來講，若是你的用戶數據可能須要和第三方共享，或者容許第三方調用 API 接口，用 Token 。若是永遠只是本身的網站，本身的 App，用什麼就無所謂了。

 

打破誤解：

「只要關閉瀏覽器 ，session就消失了？」

不對。對session來講，除非程序通知服務器刪除一個session，不然服務器會一直保留，程序通常都是在用戶作log off的時候發個指令去刪除session。

然而瀏覽器歷來不會主動在關閉以前通知服務器它將要關閉，所以服務器根本不會有機會知道瀏覽器已經關閉，之因此會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器後這個session id就消失了，再次鏈接服務器時也就沒法找到原來的session。若是服務器設置的cookie被保存在硬盤上，或者使用某種手段改寫瀏覽器發出的HTTP請求頭，把原來的session id發送給服務器，則再次打開瀏覽器仍然可以打開原來的session.

偏偏是因爲關閉瀏覽器不會致使session被刪除，迫使服務器爲session設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就能夠覺得客戶端已經中止了活動，纔會把session刪除以節省存儲空間。