這個問題，下面有回答的很詳細的了，我就簡單說一下我的理解：

1. session 和 cookie 基本上一回事情，根據協議標準，cookie 在客戶端對服務端的每次請求時，都會將其內容插入請求頭部一同傳送；

2. token 從服務端獲得後一般會儲存在 localstorage 中，在需要 token 驗證的資源請求時，開發人員才會將其插入請求頭部發送到服務端進行驗證。在請求其他無需 token 驗權的資源時無需插入，能夠節約開銷。

主要就是這麼點區別吧，以上！

Token顧名思義就是令牌、憑證、鑰匙。只有這把鑰匙，你才能開啟門。token一般都是服務端生成，比如一個web系統，使用者登入的時候，服務端校驗使用者名稱密碼通過以後，會生成一個token，同時會生成refreshToken和一個過期時間。然後將refreshToken和token返回給客戶端。客戶端會將token儲存下來。後續所有的請求都會攜帶這個token。服務端會判斷當前token是否存在已經是否過期。如果token不存在或者過期就會拒絕本次請求。如果token過期怎麼辦，就用refreshToken重新整理時間。當然這裡可能還有別的方案。比如只生成token，每次請求的時候都重新整理過期時間。如果長時間沒有重新整理過期時間，那token就會過期。

session就是回話，這是服務端的一種操作。當你第一次訪問一個web網站的時候，服務端會生成一個session，並有一個sessionid和他對應。這個session是儲存到記憶體中的，你可以向這個session中寫入資訊，比如當前登入使用者的資訊。sessionid會被返回到客戶端，客戶端一般採用cookie來儲存。當然這個cookie不用人為寫入。用tomcat容器來舉個例子。當後端呼叫HttpServletRequest物件的getSession的方法的時候，tomcat內部會生成一個jsessonid（tomcat sessionid的叫法）。這個jsessonid會隨本次請求返回給客戶端。響應頭資訊

這裡我們就會很清楚了，session的資料是儲存到記憶體中。那問題就來了，如果我們的服務是分散式部署，有多臺機器的話，可能我們第一次登陸的時候，我們把使用者的資訊儲存到了session，但是後面的請求到了B機器上，那B機器是獲取不到使用者的session的。另外就是session儲存在記憶體中，那伺服器重啟，session就丟失了，這就是他的弊端。現在有一些技術，例如session共享、iphash、session持久等也可以解決上述問題。

cookie是瀏覽器的一種策略。上述講到了sessionid就是儲存在cookie中的。我們知道http協議是無狀態的，cookie就是用來解決這個問題的。cookie中可以用來儲存服務端返回的一些使用者資訊的，例如前文提到的token、sessionid。每一次的請求，都會攜帶這些cookie。服務端從請求頭中取到cookie中的資訊，就可以識別本次請求的來源，這樣，http是不是就變成有狀態的了。這裡說幾點cookie注意事項。

cookie是瀏覽器的一種策略。上述講到了sessionid就是儲存在cookie中的。我們知道http協議是無狀態的，cookie就是用來解決這個問題的。cookie中可以用來儲存服務端返回的一些使用者資訊的，例如前文提到的token、sessionid。每一次的請求，都會攜帶這些cookie。服務端從請求頭中取到cookie中的資訊，就可以識別本次請求的來源，這樣，http是不是就變成有狀態的了。

這裡說幾點cookie注意事項。

1、cookie存放在客戶端，所以是不安全的。人為可以清除

2、cookie有過期時間設定。如果不設定過期時間，說明這個cookie就是當前瀏覽器的會話時間，瀏覽器關了，cookie 就存在了。如果有過期時間，cookie就會儲存到硬碟上，瀏覽器關閉不影響cookie。下次開啟瀏覽器，cookie還存在

3、cookie有大小的限制，4KB。

想要全面深入地掌握Token，我們需要先了解這些：Token的概念、身份驗證過程、實現思路、使用場景，以及Cookie、Session、Token的區別。

內容綱要

Token的定義

Token的身份驗證過程

Token的實現思路

Token的使用場景

Cookie和Session的區別

Token 和 Session的區別

Token的定義

Token是驗證使用者身份的一種方式，簡稱做“令牌”。最簡單的token組成：uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽，以雜湊演算法壓縮成一定長的十六進位制字串，可以防止惡意第三方拼接token請求伺服器)。還可以把不變的引數也放進token，避免多次查庫。

Token的身份驗證過程

使用者通過使用者名稱和密碼傳送請求。

程式驗證。

程式返回一個簽名的Token給客戶端。

客戶端儲存Token,並且每次用於每次傳送請求。

服務端驗證Token並返回資料。

每一次請求都需要Token,Token應該在HTTP的頭部發送，從而保證Http請求無狀態。我們同樣通過設定伺服器屬性Access-Control-Allow-Origin:* ，讓伺服器能接受到來自所有域的請求。

需要注意的是，在ACAO頭部標明(designating)*時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。

Token的實現思路

使用者登入校驗，校驗成功後就返回Token給客戶端。

客戶端收到資料後儲存在客戶端。

客戶端每次訪問API是攜帶Token到伺服器端。

伺服器端採用filter過濾器校驗。校驗成功則返回請求資料，校驗失敗則返回錯誤碼。

當我們在程式中認證了資訊，並取得Token之後，我們便能通過這個Token做許多的事情。我們甚至能基於建立一個基於許可權的token傳給第三方應用程式，這些第三方程式能夠獲取到我們的資料（當然只有在我們允許的特定的token）。

Token的應用場景

當用戶註冊、首次成功登入之後, 伺服器端會生成一個Token值，伺服器會將這個Token值儲存在資料庫中，再將這個Token值返回到客戶端。

客戶端拿到Token 值之後，進行本地儲存。

當客戶端再次傳送網路請求時（任一請求），將連同這個Token 值到引數中，一併傳送給伺服器。

伺服器接收到客戶端的請求，呼叫Token值，與儲存在資料庫中的Token值做如下對比：

如果兩個Token資料相同，即使用者曾經登入成功過，當前使用者處於登入狀態。

如果資料庫中沒有找到這個Token資料，即使用者沒有登入成功。

如果Token資料不同，說明原來的登入資訊失效，使用者需要重新登入。

儲存：Cookie資料存放在客戶的瀏覽器上，Session資料存放在伺服器上。

安全：Cookie安全性不高，黑客可以通過分析本地的Cookie記錄，然後進行Cookie欺騙。

效能：Session會在一定時間內儲存在伺服器上，當訪問量較大時，佔用伺服器，影響系統性能。

資料儲存量：單個Cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個Cookie。

綜合以上考量，建議方案：

Session和Cookie取長補短、配合使用，將登陸資訊等重要資訊存放為Session，其他資訊如果需要保留，可以放在Cookie中。

Session和Token並不矛盾，作為身份認證，Token安全性比Session高，因為Token傳送的每個請求都帶有簽名，能防止監聽，以及重放攻擊。而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的不可預測性，暫且認為是安全的，這是一種認證手段。

Session只提供一種簡單的認證，即有此SID，以及User的全部權利。是需要嚴格保密的，這個資料只在使用站點儲存，不可共享給其它網站或者第三方App。所以簡單來說，如果你的使用者資料可能需要和第三方共享，或者允許第三方呼叫API介面，則使用Token，如果只是自己的網站或App應用，使用什麼都OK。

Token，指的是OAuth Token或類似的機制的話，提供的是認證和授權 ，認證是針對使用者，授權是針對App。其目的是讓某App有權利訪問某使用者的資訊，這裡的Token是唯一的，不可以轉移到其它App上，也不可以轉到其它使用者上。

Token就是令牌，比如你授權（登入）一個程式時，他就是個依據，判斷你是否已經授權該軟體。Cookie就是寫在客戶端的一個txt檔案，記錄下使用者的訪問、登入等資訊，下次使用者再登入某個網站時，伺服器接收到請求，就會自動呼叫Cookie，自動登入使用者名稱。

Session和Cookie差不多，只是Session是寫在伺服器端的檔案，也需要在客戶端寫入Cookie檔案，但是檔案裡是使用者的瀏覽器編號.Session的狀態是儲存在伺服器端，客戶端只有session id，而Token的狀態是儲存在客戶端的。

以上，是關於Token、Session、Cookie的知識點介紹，更加深入的詳解，感興趣的童鞋，可檢視我持續分享的【BAT架構技術專題合集500+】，回覆【架構】，即可領取。

這個問題，網上有很多的答案，相信都看過了，估計也沒有看明白。所以我就不去網上覆制了，用自己的話，儘量說通俗，說重點。

cookie和session實際上是同一套認證流程，相輔相成。session儲存在伺服器，cookie儲存在客戶端。最常見的做法就是客戶端的cookie僅僅儲存一個sessionID，這個sessionID是一個毫無規則的隨機數，由伺服器在客戶端登入通過後隨機生產的。往後，客戶端每次訪問該網站都要帶上這個由sessionID組成的cookie。伺服器收到請求，首先拿到客戶端的sessionID，然後從伺服器記憶體中查詢它所代表的客戶端(使用者名稱，使用者組，有哪些許可權等)。

與token相比，這裡的重點是，伺服器必須儲存sessionID以及該ID所代表的客戶端資訊。這些內容可以儲存在記憶體，也可以儲存到資料庫(通常是記憶體資料庫)。

而token則可以伺服器完全不用儲存任何登入資訊。

token的流程是這樣的。客戶端登入通過後，伺服器生成一堆客戶端身份資訊，包括使用者名稱、使用者組、有那些許可權、過期時間等等。另外再對這些資訊進行簽名。之後把身份資訊和簽名作為一個整體傳給客戶端。這個整體就叫做token。之後，客戶端負責儲存該token，而伺服器不再儲存。客戶端每次訪問該網站都要帶上這個token。伺服器收到請求後，把它分割成身份資訊和簽名，然後驗證簽名，若驗證成功，就直接使用身份資訊(使用者名稱、使用者組、有哪些許可權等等)。

可以看出，相對於cookie/session機制，token機制中，伺服器根本不需要儲存使用者的身份資訊(使用者名稱、使用者組、許可權等等)。這樣就減輕了伺服器的負擔。

我們舉個例來說，假如目前有一千萬個使用者登入了，在訪問不同的網頁。如果用cookie/session，則伺服器記憶體(或記憶體資料庫)中要同時記錄1千萬個使用者的資訊。每次客戶端訪問一個頁面，伺服器都要從記憶體中查詢出他的登入資訊。而如果用token，則伺服器記憶體中不記錄使用者登入資訊。它只需要在收到請求後，直接使用客戶端發過來的登入身份資訊。

可以這麼說，cookie/session是伺服器說客戶端是誰，客戶端才是誰。而token是客戶端說我(客戶端)是誰，我就是誰。當然了，token是有簽名機制的。要是客戶端偽造身份，簽名通不過。這個簽名演算法很簡單，就是將客戶端的身份資訊加上一個只有伺服器知道的鹽值(不能洩露)，然後進行md5雜湊演算法(這裡只是簡化，方便理解，實際細節要稍複雜一些)。

cookie/session在單伺服器，單域名時比較簡單，否則的話，就要考慮如何將客戶端的session儲存或同步到多個伺服器。還要考慮一旦宕機，記憶體中的這些資訊是否會丟失。token因為伺服器不儲存使用者身份，就不存在這個問題。這是token的優點。

token因為伺服器不儲存使用者身份資訊，一切都依賴當初那個簽名。所以存在被盜用的風險。也就是說一旦盜用，伺服器可能毫無辦法，因為它只認簽名演算法。而session機制，伺服器看誰不爽，可以隨時把他踢出(從記憶體中刪掉)。正是因為如此，token高度依賴過期時間。過期時間不能太長。過期短，可以減少被盜用的風險。

除了上面所說的，我個人認為，如果開發的系統足夠小，傾向於使用cookie/session。如果系統同時登入使用者多，叢集伺服器多，有單點登入需求，則傾向於使用token。

session

session的中文翻譯是“會話”，當用戶開啟某個web應用時，便與web伺服器產生一次session。伺服器使用session把使用者的資訊臨時儲存在了伺服器上，使用者離開網站後session會被銷燬。這種使用者資訊儲存方式相對cookie來說更安全，可是session有一個缺陷：如果web伺服器做了負載均衡，那麼下一個操作請求到了另一臺伺服器的時候session會丟失。

cookie

cookie是儲存在本地終端的資料。cookie由伺服器生成，傳送給瀏覽器，瀏覽器把cookie以kv形式儲存到某個目錄下的文字檔案內，下一次請求同一網站時會把該cookie傳送給伺服器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會佔據太多磁碟空間，所以每個域的cookie數量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設定為全域性:"")、失效時間、安全標誌(指定後，cookie只有在使用SSL連線時才傳送到伺服器(https))。下面是一個簡單的js使用cookie的例子:

使用者登入時產生cookie:

document.cookie = "id="+result.data["id"]+"; path=/";

document.cookie = "name="+result.data["name"]+"; path=/";

document.cookie = "avatar="+result.data["avatar"]+"; path=/";

使用到cookie時做如下解析：

var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {

user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];

}

$("#user_name").text(user_info[" name"]);

$("#user_avatar").attr("src", user_info[" avatar"]);

$("#user_id").val(user_info[" id"]);

token

token的意思是“令牌”，是使用者身份的驗證方式，最簡單的token組成:uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進位制字串，可以防止惡意第三方拼接token請求伺服器)。還可以把不變的引數也放進token，避免多次查庫

cookie 和session的區別

1、cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上。

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

考慮到安全應當使用session。

3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能

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

4、單個cookie儲存的資料不能超過4K，很多瀏覽器都限制一個站點最多儲存20個cookie。

5、所以個人建議：

將登陸資訊等重要資訊存放為SESSION

其他資訊如果需要保留，可以放在COOKIE中

token 和session 的區別

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，用什麼就無所謂了。

token就是令牌，比如你授權（登入）一個程式時，他就是個依據，判斷你是否已經授權該軟體；cookie就是寫在客戶端的一個txt檔案，裡面包括你登入資訊之類的，這樣你下次在登入某個網站，就會自動呼叫cookie自動登入使用者名稱；session和cookie差不多，只是session是寫在伺服器端的檔案，也需要在客戶端寫入cookie檔案，但是檔案裡是你的瀏覽器編號.Session的狀態是儲存在伺服器端，客戶端只有session id；而Token的狀態是儲存在客戶端。

　

在Web開發領域，相信大家對於Cookie和Session都很熟悉，Cookie和Session都是會話保持技術的解決方案。隨著技術的發展，Token機制出現在我們面前，不過很多開發者對於Token和Cookie、Session的區別及使用場景分辨不清。

Cookie和Session的用途

要知道我們訪問網站都是通過HTTP協議或HTTPS協議來完成的，HTTP協議它本身是無狀態的協議（即：伺服器無法分辨哪些請求是來源於同個客戶）。而業務層面會涉及到客戶端與伺服器端的互動（同網站下多個頁面間能共享資料），此時伺服器端必須要保持會話狀態，這樣才能進行使用者身份的鑑別。

由於HTTP無狀態的特性，如果要實話客戶端和伺服器端的會話保持，那就需要其它機制來實現，於是Cookie和Session應運而生。

通常情況下，Session和Cookie是搭配在一起使用的。

Token是什麼

上面說到的Session和Cookie機制來保持會話，會存在一個問題：客戶端瀏覽器只要儲存自己的SessionID即可，而伺服器卻要儲存所有使用者的Session資訊，這對於伺服器來說開銷較大，而且不利用伺服器的擴充套件（比如伺服器叢集時，Session如何同步儲存就是個問題）！

於是有人思考，如果把Session資訊讓客戶端來保管而且無法偽造不就可以解決這個問題了？進而有了Token機制。

Token俗稱為“令牌”，它的構成是：

uid：使用者唯一身份標識

timestamp：當前時間戳

sign：簽名字串，防止第三方偽造資料；簽名金鑰是儲存在伺服器端的，其它人無法知道

其它附加引數。

Token機制下的認證流程

Token機制其實和Cookie機制極其相似，主要有以下流程：

1、使用者登入進行身份認證，認證成功後伺服器端生成Token返回給客戶端；

2、客戶端接收到Token後儲存在客戶端（可儲存在Cookie、LocalStorage、SessionStorage中）；

3、客戶端再次請求伺服器端時，將Token作為請求頭放入Headers中；

4、伺服器端接收請求頭中的Token，將使用者引數按照既定規則再進行一次簽名，兩次簽名若一致則認為成功，反之資料存在篡改請求失敗。

（驗證簽名示例圖）

Token與Cookie+Session的區別

Cookie其實也充當的是令牌作用，但它是“有狀態”的；而Token令牌是無狀態的，更利於分散式部署。

Token, 令牌，代表執行某些操作的權利的物件。

token主要用於鑑權使用，主要有以下幾類：

訪問令牌（Access token）表示訪問控制操作主體的系統物件邀請碼，在邀請系統中使用Token, Petri 網（Petri net）理論中的Token密保令牌（Security token），或者硬體令牌，例如U盾，或者叫做認證令牌或者加密令牌，一種計算機身份校驗的物理裝置會話令牌（Session token）,互動會話中唯一身份識別符號令牌化技術 (Tokenization), 取代敏感資訊條目的處理過程

cookie主要是網站用於在瀏覽器臨時存放的資料，包括瀏覽器快取資料以及伺服器設定的一些資料，主要存放在瀏覽器端。

session主要用於儲存會話資料，一般儲存在伺服器端，同時每一條session對用一個sessionID，sessionID是存放在瀏覽器的cookie中。

傳統上的會話登陸和鑑權主要用session加cookie實現，隨著分散式系統的快速演進，尤其是微服務的應用，token+cookie的授權訪問機制得到親睞，通常在使用者登入後，伺服器生成訪問令牌(Access token)，瀏覽器儲存cookie中，在每次請求資源時都會在請求頭中帶上token，用於伺服器授權訪問使用。