session和cookie

在講Token之前，先簡單說說什么是session和cookie。

• 首先要知道HTTP請求是無狀態(tài)的，也就是不知道這一次的請求和上一次請求是否有關(guān)系，比如我們登錄一個系統(tǒng)的時候，驗證用戶名密碼之后，打開系統(tǒng)各個頁面的時候就不需要再進(jìn)行登錄操作了，直到我們主動退出登錄或超時退出登錄；這里為了避免訪問每個都登錄一下，就要用到session、cookie。
  

• cookie是在客戶端(瀏覽器)保存用戶信息的一種機(jī)制；而且每種瀏覽器存儲大小會有一些差異，一般不超過4KB；
  

• session是在服務(wù)端保存，可以用于記錄客戶狀態(tài)，比如我們經(jīng)常會用session保存客戶的基本信息、權(quán)限信息等；用戶第一次登錄之后，服務(wù)器就會創(chuàng)建一個session，瀏覽器再次訪問時，只需要從該session中查找該客戶的信息就可以了。
  

Token

但是這里會有個問題，服務(wù)器要保存所有用戶的session信息，開銷會很大，如果在分布式的架構(gòu)下，就需要考慮session共享的問題，需要做額外的設(shè)計和開發(fā)，例如把session中的信息保存到Redis中進(jìn)行共享；所以因為這個原因，有人考慮這些信息是否可以讓客戶端保存，可以保存到任何地方，并且保證其安全性，于是就有了Token。

Token是服務(wù)端生成的一串字符串，可以看做客戶端進(jìn)行請求的一個令牌。

• 當(dāng)客戶端第一次訪問服務(wù)端，服務(wù)端會根據(jù)傳過來的唯一標(biāo)識userId，運用一些加密算法，生成一個Token，客戶端下次請求時，只需要帶上Token，服務(wù)器收到請求后，會驗證這個Token。
  

• 有些公司會建設(shè)統(tǒng)一登錄系統(tǒng)（單點登錄），客戶端先去這個系統(tǒng)獲取Token，驗證通過再拿著這些Token去訪問其他系統(tǒng)；API Gateway也可以提供類似的功能，我們公司就是這樣，客戶端接入的時候，先向網(wǎng)關(guān)獲取Token，驗證通過了才能訪問被授權(quán)的接口，并且一段時間后要重新或者Token。

基于Token的認(rèn)證流程

整體的流程是這樣的：

1. 客戶端使用用戶名、密碼做身份驗證；
   

2. 服務(wù)端收到請求后進(jìn)行身份驗證；(也可能是統(tǒng)一登錄平臺、網(wǎng)關(guān))
   

3. 驗證成功后，服務(wù)端會簽發(fā)一個Token返回給客戶端；
   

4. 客戶端收到Token以后可以把它存儲起來（可以放在）；每次向服務(wù)端發(fā)送請求的時候，都要帶著Token；
   

5. Token會有過期時間，過期后需要重新進(jìn)行驗證；
   

6. 服務(wù)端收到請求，會驗證客戶端請求里面的Token，驗證成功，才會響應(yīng)客戶端的請求；
   

總結(jié)

• cookie：保存在瀏覽器種，有大小限制，有狀態(tài)；
  

• session：保存在服務(wù)器中，服務(wù)器有資源開銷，分布式、跨系統(tǒng)不好實現(xiàn)；
  

• Token：客戶端可以將Token保存到任何地方，無限制，無狀態(tài)，利于分布式部署。
  

希望我的回答，能夠幫助到你！我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。

在Web開發(fā)領(lǐng)域，相信大家對于Cookie和Session都很熟悉，Cookie和Session都是會話保持技術(shù)的解決方案。隨著技術(shù)的發(fā)展，Token機(jī)制出現(xiàn)在我們面前，不過很多開發(fā)者對于Token和Cookie、Session的區(qū)別及使用場景分辨不清。

Cookie和Session的用途

要知道我們訪問網(wǎng)站都是通過HTTP協(xié)議或HTTPS協(xié)議來完成的，HTTP協(xié)議它本身是無狀態(tài)的協(xié)議（即：服務(wù)器無法分辨哪些請求是來源于同個客戶）。而業(yè)務(wù)層面會涉及到客戶端與服務(wù)器端的交互（同網(wǎng)站下多個頁面間能共享數(shù)據(jù)），此時服務(wù)器端必須要保持會話狀態(tài)，這樣才能進(jìn)行用戶身份的鑒別。

由于HTTP無狀態(tài)的特性，如果要實話客戶端和服務(wù)器端的會話保持，那就需要其它機(jī)制來實現(xiàn)，于是Cookie和Session應(yīng)運而生。

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

Token是什么

上面說到的Session和Cookie機(jī)制來保持會話，會存在一個問題：客戶端瀏覽器只要保存自己的SessionID即可，而服務(wù)器卻要保存所有用戶的Session信息，這對于服務(wù)器來說開銷較大，而且不利用服務(wù)器的擴(kuò)展（比如服務(wù)器集群時，Session如何同步存儲就是個問題）！

于是有人思考，如果把Session信息讓客戶端來保管而且無法偽造不就可以解決這個問題了？進(jìn)而有了Token機(jī)制。

Token俗稱為“令牌”，它的構(gòu)成是：

• uid：用戶唯一身份標(biāo)識

• timestamp：當(dāng)前時間戳

• sign：簽名字符串，防止第三方偽造數(shù)據(jù)；簽名密鑰是存儲在服務(wù)器端的，其它人無法知道

• 其它附加參數(shù)。

Token機(jī)制下的認(rèn)證流程

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

1、用戶登錄進(jìn)行身份認(rèn)證，認(rèn)證成功后服務(wù)器端生成Token返回給客戶端；

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

3、客戶端再次請求服務(wù)器端時，將Token作為請求頭放入Headers中；

4、服務(wù)器端接收請求頭中的Token，將用戶參數(shù)按照既定規(guī)則再進(jìn)行一次簽名，兩次簽名若一致則認(rèn)為成功，反之?dāng)?shù)據(jù)存在篡改請求失敗。

（生成簽名示例圖）

（驗證簽名示例圖）

Token與Cookie+Session的區(qū)別

Cookie其實也充當(dāng)?shù)氖橇钆谱饔�，但它是“有狀態(tài)”的；而Token令牌是無狀態(tài)的，更利于分布式部署。

以上就是我的觀點，對于這個問題大家是怎么看待的呢？歡迎在下方評論區(qū)交流 ~ 我是科技領(lǐng)域創(chuàng)作者，十年互聯(lián)網(wǎng)從業(yè)經(jīng)驗，歡迎關(guān)注我了解更多科技知識！

Token顧名思義就是令牌、憑證、鑰匙。只有這把鑰匙，你才能打開門。token一般都是服務(wù)端生成，比如一個web系統(tǒng)，用戶登錄的時候，服務(wù)端校驗用戶名密碼通過以后，會生成一個token，同時會生成refreshToken和一個過期時間。然后將refreshToken和token返回給客戶端�？蛻舳藭�將token保存下來。后續(xù)所有的請求都會攜帶這個token。服務(wù)端會判斷當(dāng)前token是否存在已經(jīng)是否過期。如果token不存在或者過期就會拒絕本次請求。如果token過期怎么辦，就用refreshToken刷新時間。當(dāng)然這里可能還有別的方案。比如只生成token，每次請求的時候都刷新過期時間。如果長時間沒有刷新過期時間，那token就會過期。

session就是回話，這是服務(wù)端的一種操作。當(dāng)你第一次訪問一個web網(wǎng)站的時候，服務(wù)端會生成一個session，并有一個sessionid和他對應(yīng)。這個session是存儲到內(nèi)存中的，你可以向這個session中寫入信息，比如當(dāng)前登錄用戶的信息。sessionid會被返回到客戶端，客戶端一般采用cookie來保存。當(dāng)然這個cookie不用人為寫入。用tomcat容器來舉個例子。當(dāng)后端調(diào)用HttpServletRequest對象的getSession的方法的時候，tomcat內(nèi)部會生成一個jsessonid（tomcat sessionid的叫法）。這個jsessonid會隨本次請求返回給客戶端。響應(yīng)頭信息

HTTP/1.1 200 OK
Set-Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxx

這個jessionid就會寫到cookie中。之后jessionid就會通過cookie傳遞到服務(wù)端。

這里我們就會很清楚了，session的數(shù)據(jù)是存儲到內(nèi)存中。那問題就來了，如果我們的服務(wù)是分布式部署，有多臺機(jī)器的話，可能我們第一次登陸的時候，我們把用戶的信息存儲到了session，但是后面的請求到了B機(jī)器上，那B機(jī)器是獲取不到用戶的session的。另外就是session存儲在內(nèi)存中，那服務(wù)器重啟，session就丟失了，這就是他的弊端�，F(xiàn)在有一些技術(shù)，例如session共享、iphash、session持久等也可以解決上述問題。

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

這里說幾點cookie注意事項。

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

2、cookie有過期時間設(shè)定。如果不設(shè)置過期時間，說明這個cookie就是當(dāng)前瀏覽器的會話時間，瀏覽器關(guān)了，cookie 就存在了。如果有過期時間，cookie就會存儲到硬盤上，瀏覽器關(guān)閉不影響cookie。下次打開瀏覽器，cookie還存在

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

這個問題，網(wǎng)上有很多的答案，相信都看過了，估計也沒有看明白。所以我就不去網(wǎng)上復(fù)制了，用自己的話，盡量說通俗，說重點。

cookie和session實際上是同一套認(rèn)證流程，相輔相成。session保存在服務(wù)器，cookie保存在客戶端。最常見的做法就是客戶端的cookie僅僅保存一個sessionID，這個sessionID是一個毫無規(guī)則的隨機(jī)數(shù)，由服務(wù)器在客戶端登錄通過后隨機(jī)生產(chǎn)的。往后，客戶端每次訪問該網(wǎng)站都要帶上這個由sessionID組成的cookie。服務(wù)器收到請求，首先拿到客戶端的sessionID，然后從服務(wù)器內(nèi)存中查詢它所代表的客戶端(用戶名，用戶組，有哪些權(quán)限等)。

與token相比，這里的重點是，服務(wù)器必須保存sessionID以及該ID所代表的客戶端信息。這些內(nèi)容可以保存在內(nèi)存，也可以保存到數(shù)據(jù)庫(通常是內(nèi)存數(shù)據(jù)庫)。

而token則可以服務(wù)器完全不用保存任何登錄信息。

token的流程是這樣的�？蛻舳说卿浲ㄟ^后，服務(wù)器生成一堆客戶端身份信息，包括用戶名、用戶組、有那些權(quán)限、過期時間等等。另外再對這些信息進(jìn)行簽名。之后把身份信息和簽名作為一個整體傳給客戶端。這個整體就叫做token。之后，客戶端負(fù)責(zé)保存該token，而服務(wù)器不再保存�？蛻舳嗣看卧L問該網(wǎng)站都要帶上這個token。服務(wù)器收到請求后，把它分割成身份信息和簽名，然后驗證簽名，若驗證成功，就直接使用身份信息(用戶名、用戶組、有哪些權(quán)限等等)。

可以看出，相對于cookie/session機(jī)制，token機(jī)制中，服務(wù)器根本不需要保存用戶的身份信息(用戶名、用戶組、權(quán)限等等)。這樣就減輕了服務(wù)器的負(fù)擔(dān)。

我們舉個例來說，假如目前有一千萬個用戶登錄了，在訪問不同的網(wǎng)頁。如果用cookie/session，則服務(wù)器內(nèi)存(或內(nèi)存數(shù)據(jù)庫)中要同時記錄1千萬個用戶的信息。每次客戶端訪問一個頁面，服務(wù)器都要從內(nèi)存中查詢出他的登錄信息。而如果用token，則服務(wù)器內(nèi)存中不記錄用戶登錄信息。它只需要在收到請求后，直接使用客戶端發(fā)過來的登錄身份信息。

可以這么說，cookie/session是服務(wù)器說客戶端是誰，客戶端才是誰。而token是客戶端說我(客戶端)是誰，我就是誰。當(dāng)然了，token是有簽名機(jī)制的。要是客戶端偽造身份，簽名通不過。這個簽名算法很簡單，就是將客戶端的身份信息加上一個只有服務(wù)器知道的鹽值(不能泄露)，然后進(jìn)行md5散列算法(這里只是簡化，方便理解，實際細(xì)節(jié)要稍復(fù)雜一些)。

cookie/session在單服務(wù)器，單域名時比較簡單，否則的話，就要考慮如何將客戶端的session保存或同步到多個服務(wù)器。還要考慮一旦宕機(jī)，內(nèi)存中的這些信息是否會丟失。token因為服務(wù)器不保存用戶身份，就不存在這個問題。這是token的優(yōu)點。

token因為服務(wù)器不保存用戶身份信息，一切都依賴當(dāng)初那個簽名。所以存在被盜用的風(fēng)險。也就是說一旦盜用，服務(wù)器可能毫無辦法，因為它只認(rèn)簽名算法。而session機(jī)制，服務(wù)器看誰不爽，可以隨時把他踢出(從內(nèi)存中刪掉)。正是因為如此，token高度依賴過期時間。過期時間不能太長。過期短，可以減少被盜用的風(fēng)險。

除了上面所說的，我個人認(rèn)為，如果開發(fā)的系統(tǒng)足夠小，傾向于使用cookie/session。如果系統(tǒng)同時登錄用戶多，集群服務(wù)器多，有單點登錄需求，則傾向于使用token。

一、首先我們先解釋一下什么是Token？

Token的定義：Token是服務(wù)端生成的一串字符串，以作客戶端進(jìn)行請求的一個令牌，當(dāng)?shù)谝淮蔚卿浐�，服�?wù)器生成一個Token便將此Token返回給客戶端，以后客戶端只需帶上這個Token前來請求數(shù)據(jù)即可，無需再次帶上用戶名和密碼。

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

了解了Token的意義后，我們就更明確的知道為什么要用他了。

二、如何使用Token？

（1） 客戶端：客戶端在登錄的時候獲取設(shè)備的設(shè)備號/mac地址，并將其作為參數(shù)傳遞到服務(wù)端。

（2）服務(wù)端：服務(wù)端接收到該參數(shù)后，便用一個變量來接收同時將其作為Token保存在數(shù)據(jù)庫，并將該Token設(shè)置到session中，客戶端每次請求的時候都要統(tǒng)一攔截，并將客戶端傳遞的token和服務(wù)器端session中的token進(jìn)行對比，如果相同則放行，不同則拒絕。

至于使用場景區(qū)別精簡如下：

token就是令牌，比如你授權(quán)（登錄）一個程序時，他就是個依據(jù)，判斷你是否已經(jīng)授權(quán)該軟件；

cookie就是寫在客戶端的一個txt文件，里面包括你登錄信息之類的，這樣你下次在登錄某個網(wǎng)站，就會自動調(diào)用cookie自動登錄用戶名；

session和cookie差不多，只是session是寫在服務(wù)器端的文件，也需要在客戶端寫入cookie文件，但是文件里是你的瀏覽器編號

Session的狀態(tài)是存儲在服務(wù)器端，客戶端只有session id；而Token的狀態(tài)是存儲在客戶端。

綜述：

cookie：保存在瀏覽器種，有大小限制，有狀態(tài)；

session：保存在服務(wù)器中，服務(wù)器有資源開銷，分布式、跨系統(tǒng)不好實現(xiàn)；

Token：客戶端可以將Token保存到任何地方，無限制，無狀態(tài)，利于分布式部署。

是不是回答的界面有點素了，沒辦法機(jī)械男回答這種代碼問題就是如此暴力！

記得點贊，評論吧！

Token, 令牌，代表執(zhí)行某些操作的權(quán)利的對象。

token主要用于鑒權(quán)使用，主要有以下幾類：

• 訪問令牌（Access token）表示訪問控制操作主體的系統(tǒng)對象
• 邀請碼，在邀請系統(tǒng)中使用
• Token, Petri 網(wǎng)（Petri net）理論中的Token
• 密保令牌（Security token），或者硬件令牌，例如U盾，或者叫做認(rèn)證令牌或者加密令牌，一種計算機(jī)身份校驗的物理設(shè)備
• 會話令牌（Session token）,交互會話中唯一身份標(biāo)識符
• 令牌化技術(shù) (Tokenization), 取代敏感信息條目的處理過程

cookie主要是網(wǎng)站用于在瀏覽器臨時存放的數(shù)據(jù)，包括瀏覽器緩存數(shù)據(jù)以及服務(wù)器設(shè)定的一些數(shù)據(jù)，主要存放在瀏覽器端。

session主要用于保存會話數(shù)據(jù)，一般存儲在服務(wù)器端，同時每一條session對用一個sessionID，sessionID是存放在瀏覽器的cookie中。

傳統(tǒng)上的會話登陸和鑒權(quán)主要用session加cookie實現(xiàn)，隨著分布式系統(tǒng)的快速演進(jìn)，尤其是微服務(wù)的應(yīng)用，token+cookie的授權(quán)訪問機(jī)制得到親睞，通常在用戶登錄后，服務(wù)器生成訪問令牌(Access token)，瀏覽器存儲cookie中，在每次請求資源時都會在請求頭中帶上token，用于服務(wù)器授權(quán)訪問使用。

Token和session都是web網(wǎng)站的會話保持、認(rèn)證的解決方案；

既然都一樣為什么還有token的說法。

從token產(chǎn)生的背景說起

1.移動端應(yīng)用使得服務(wù)器端Session失效

2.分布式系統(tǒng)中Session無法共享

所以說session對于以上兩種情況無效了，所以有了Token的說法

那么什么是token,token長什么樣子？

先給大家一個直觀的感受

token:PC-3066014fa0b10792e4a762-23-20170531133947-4f6496

說白了token保存就是用戶的信息（不能保存密碼等敏感信息）

token的組成：

客戶端標(biāo)識-USERCODE-USERID-CREATIONDATE-RONDEM[6位]

USERCODE，RONDEM[6位]經(jīng)過MD5加密就變成了以上字符串

token的請求流程

請求流程解析

1.前端用戶發(fā)送登錄信息至認(rèn)證系統(tǒng)

2.驗證用戶登錄信息，判斷用戶是否存在

3.如果用戶存在，生成token信息（客戶端標(biāo)識-USERCODE-USERID-CREATIONDATE-RONDEM[6位]），并存儲在redis中

4.并將該token返回前端，附加至header

驗證token

客戶端

將token附加至header

服務(wù)端

1. 從客戶端請求header中取出token

2. 與redis中的token進(jìn)行比對，如果一致則允許訪問。

最后總結(jié)一下

一般的垂直架構(gòu)項目使用Session沒有任何問題，但是分布式項目或涉及到移動端則考慮使用token。

由Session到Token的身份驗證演變過程理解Session、Cookie、Token

本文將從Web應(yīng)用 由傳統(tǒng)身份驗證到基于Token的身份驗證的演變過程的角度，介紹Session、Cookie、Token。

很久以前，Web 應(yīng)用基本用作文檔的瀏覽，如網(wǎng)絡(luò)黃頁。既然僅僅是瀏覽，因此服務(wù)器不需要記錄具體用戶在某一段時間里都瀏覽了哪些文檔，每次請求都是一個新的HTTP協(xié)議，對服務(wù)器來說都是全新的。

基于Session的身份驗證

隨著交互式Web應(yīng)用的興起，比如，購物等需要登錄的網(wǎng)站。引出了一個新的問題，那就是要記錄哪些用戶登錄了系統(tǒng)進(jìn)行了哪些操作，即要管理會話（什么是會話？簡單的講如果用戶需要登錄，那么就可以簡單的理解為會話，如果不需要登錄，那么就是簡單的連接。），比如，不同用戶將不同商品加入到購物車中， 也就是說必須把每個用戶區(qū)分開。因為HTTP請求是無狀態(tài)的，所以想出了一個辦法，那就是給每個用戶配發(fā)一個會話標(biāo)識(Session id)，簡單的講就是一個既不會重復(fù)，又不容易被找到規(guī)律以仿造的隨機(jī)字符串，使得每個用戶的收到的會話標(biāo)識都不一樣， 每次用戶從客戶端向服務(wù)端發(fā)起HTTP請求的時候，把這個字符串給一并發(fā)送過來， 這樣服務(wù)端就能區(qū)分開誰是誰了，至于客戶端（瀏覽器）如何保存這個“身份標(biāo)識”，一般默認(rèn)采用 Cookie 的方式，這個會話標(biāo)識(Session id)會存在客戶端的Cookie中。

雖然這樣解決了區(qū)分用戶的問題，但又引發(fā)了一個新的問題，那就是每個用戶（客戶端）只需要保存自己的會話標(biāo)識(Session id)，而服務(wù)端則要保存所有用戶的會話標(biāo)識(Session id)。 如果訪問服務(wù)端的用戶逐漸變多， 就需要保存成千上萬，甚至幾千萬個，這對服務(wù)器說是一個難以接受的開銷 。 再比如，服務(wù)端是由2臺服務(wù)器組成的一個集群， 小明通過服務(wù)器A登錄了系統(tǒng)， 那session id會保存在服務(wù)器A上， 假設(shè)小明的下一次請求被轉(zhuǎn)發(fā)到服務(wù)器B怎么辦？ 服務(wù)器B可沒有小明 的 session id。

可能會有人講，如果使小明登錄時，始終在服務(wù)器A上進(jìn)行登錄（sticky session），豈不解決了這個問題？那如果服務(wù)器A掛掉怎么辦呢？ 還是會將小明的請求轉(zhuǎn)發(fā)到服務(wù)器B上。

如此一來，那只能做集群間的 session 復(fù)制共享了， 就是把 session id 在兩個機(jī)器之間進(jìn)行復(fù)制，如下圖，但這對服務(wù)器的性能和內(nèi)存提出了巨大的挑戰(zhàn)。

因此，又想到如果將所有用戶的Session集中存儲呢，也就想到了緩存服務(wù)Memcached——由于 Memcached 是分布式的內(nèi)存對象緩存系統(tǒng)，因此可以用來實現(xiàn) Session 同步。把session id 集中存儲到一臺服務(wù)器上， 所有的服務(wù)器都來訪問這個地方的數(shù)據(jù)， 如此就避免了復(fù)制的方式， 但是這種“集萬千寵愛于一身”使得又出現(xiàn)了單點故障的可能， 就是說這個負(fù)責(zé)存儲 session 的服務(wù)器掛了， 所有用戶都得重新登錄一遍， 這是用戶難以接受的。

那么索性存儲Session的服務(wù)器也搞成集群，增加其可靠性，避免單點故障，但不管如何，Session 引發(fā)出來的問題層出不窮。

于是有人就在思考， 為什么服務(wù)端必須要保存這session呢， 只讓每個客戶端去保存不行嗎？可是服務(wù)端如果不保存這些session id ，又將如何驗證客戶端發(fā)送的 session id 的確是服務(wù)端生成的呢？ 如果不驗證，服務(wù)端無法判斷是否是合法登錄的用戶，對，這里的問題是驗證， session 只是解決這個驗證問題的而產(chǎn)生的一個解決方案，是否還有其它方案呢？

基于Token 的身份驗證

例如， 小明已經(jīng)登錄了系統(tǒng)，服務(wù)端給他發(fā)一個令牌(Token)， 里邊包含了小明的 user id， 后續(xù)小明再次通過 Http 請求訪問服務(wù)器的時候， 把這個 Token 通過 Http header 帶過來不就可以了。

服務(wù)端需要驗證 Token是自己生成的，而非偽造的。假如不驗證任何人都可以偽造，那么這個令牌(token)和 session id沒有本質(zhì)區(qū)別，如何讓別人偽造不了？那就對數(shù)據(jù)做一個簽名（Sign）吧， 比如說服務(wù)端用 HMAC-SHA256 加密算法，再加上一個只有服務(wù)端才知道的密鑰， 對數(shù)據(jù)做一個簽名， 把這個簽名和數(shù)據(jù)一起作為 Token 發(fā)給客戶端， 客戶端收到 Token 以后可以把它存儲起來，比如存儲在 Cookie 里或者 Local Storage 中，由于密鑰除了服務(wù)端任何其他用戶都不知道， 就無法偽造令牌(Token)。

如此一來，服務(wù)端就不需要保存 Token 了， 當(dāng)小明把這個Token發(fā)給服務(wù)端時，服務(wù)端使用相同的HMAC-SHA256 算法和相同的密鑰，對數(shù)據(jù)再計算一次簽名， 和 Token 中的簽名做個對比， 如果相同，說明小明已經(jīng)登錄過了， 即驗證成功。若不相同， 那么說明這個請求是偽造的。

這樣一來， 服務(wù)端只需要生成 Token，而不需要保存Token， 只是驗證Token就好了 ，也就實現(xiàn)了時間換取空間（CPU計算時間換取session 存儲空間）。沒了session id 的限制， 當(dāng)用戶訪問量增大， 直接加機(jī)器就可以輕松地做水平擴(kuò)展，也極大的提高了可擴(kuò)展性。

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

內(nèi)容綱要

• Token的定義

• Token的身份驗證過程

• Token的實現(xiàn)思路

• Token的使用場景

• Cookie和Session的區(qū)別

• Token 和 Session的區(qū)別

Token的定義

Token是驗證用戶身份的一種方式，簡稱做“令牌”。最簡單的token組成：uid(用戶唯一的身份標(biāo)識)、time(當(dāng)前時間的時間戳)、sign(簽名，由token的前幾位+鹽，以哈希算法壓縮成一定長的十六進(jìn)制字符串，可以防止惡意第三方拼接token請求服務(wù)器)。還可以把不變的參數(shù)也放進(jìn)token，避免多次查庫。

Token的身份驗證過程

1. 用戶通過用戶名和密碼發(fā)送請求。

2. 程序驗證。

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

4. 客戶端儲存Token,并且每次用于每次發(fā)送請求。

5. 服務(wù)端驗證Token并返回數(shù)據(jù)。

每一次請求都需要Token,Token應(yīng)該在HTTP的頭部發(fā)送，從而保證Http請求無狀態(tài)。我們同樣通過設(shè)置服務(wù)器屬性Access-Control-Allow-Origin:* ，讓服務(wù)器能接受到來自所有域的請求。

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

Token的實現(xiàn)思路

1. 用戶登錄校驗，校驗成功后就返回Token給客戶端。

2. 客戶端收到數(shù)據(jù)后保存在客戶端。

3. 客戶端每次訪問API是攜帶Token到服務(wù)器端。

4. 服務(wù)器端采用filter過濾器校驗。校驗成功則返回請求數(shù)據(jù)，校驗失敗則返回錯誤碼。

當(dāng)我們在程序中認(rèn)證了信息，并取得Token之后，我們便能通過這個Token做許多的事情。我們甚至能基于創(chuàng)建一個基于權(quán)限的token傳給第三方應(yīng)用程序，這些第三方程序能夠獲取到我們的數(shù)據(jù)（當(dāng)然只有在我們允許的特定的token）。

Token的應(yīng)用場景

1. 當(dāng)用戶注冊、首次成功登錄之后, 服務(wù)器端會生成一個Token值，服務(wù)器會將這個Token值保存在數(shù)據(jù)庫中，再將這個Token值返回到客戶端。

2. 客戶端拿到Token 值之后，進(jìn)行本地保存。

3. 當(dāng)客戶端再次發(fā)送網(wǎng)絡(luò)請求時（任一請求），將連同這個Token 值到參數(shù)中，一并傳送給服務(wù)器。

4. 服務(wù)器接收到客戶端的請求，調(diào)用Token值，與保存在數(shù)據(jù)庫中的Token值做如下對比：

• 如果兩個Token數(shù)據(jù)相同，即用戶曾經(jīng)登錄成功過，當(dāng)前用戶處于登錄狀態(tài)。

• 如果數(shù)據(jù)庫中沒有找到這個Token數(shù)據(jù)，即用戶沒有登錄成功。

• 如果Token數(shù)據(jù)不同，說明原來的登錄信息失效，用戶需要重新登錄。

Cookie和Session的區(qū)別

1. 存儲：Cookie數(shù)據(jù)存放在客戶的瀏覽器上，Session數(shù)據(jù)存放在服務(wù)器上。

2. 安全：Cookie安全性不高，黑客可以通過分析本地的Cookie記錄，然后進(jìn)行Cookie欺騙。

3. 性能：Session會在一定時間內(nèi)保存在服務(wù)器上，當(dāng)訪問量較大時，占用服務(wù)器，影響系統(tǒng)性能。

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

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

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

Token 和 Session 的區(qū)別

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

App通常用Restful API跟server打交道。Rest是Stateless的，也就是App不需要像Browser那樣用Cookie來保存Session，因此使用Session Token來標(biāo)示就足夠了。Session/state由API Server的邏輯處理。如果后端不是Stateless的rest API，那么可能需要在App里保存Session，可以在App里嵌入webkit，用一個隱藏的Browser來管理Cookie Session.

Session是一種HTTP存儲機(jī)制，目的是為無狀態(tài)的HTTP提供持久機(jī)制。所謂的Session認(rèn)證，只是簡單的把User信息存儲到Session里，因為SID的不可預(yù)測性，暫且認(rèn)為是安全的，這是一種認(rèn)證手段。

Session只提供一種簡單的認(rèn)證，即有此SID，以及User的全部權(quán)利。是需要嚴(yán)格保密的，這個數(shù)據(jù)只在使用站點保存，不可共享給其它網(wǎng)站或者第三方App。所以簡單來說，如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用API接口，則使用Token，如果只是自己的網(wǎng)站或App應(yīng)用，使用什么都OK。

Token，指的是OAuth Token或類似的機(jī)制的話，提供的是認(rèn)證和授權(quán) ，認(rèn)證是針對用戶，授權(quán)是針對App。其目的是讓某App有權(quán)利訪問某用戶的信息，這里的Token是唯一的，不可以轉(zhuǎn)移到其它App上，也不可以轉(zhuǎn)到其它用戶上。

Token就是令牌，比如你授權(quán)（登錄）一個程序時，他就是個依據(jù)，判斷你是否已經(jīng)授權(quán)該軟件。Cookie就是寫在客戶端的一個txt文件，記錄下用戶的訪問、登錄等信息，下次用戶再登錄某個網(wǎng)站時，服務(wù)器接收到請求，就會自動調(diào)用Cookie，自動登錄用戶名。

Session和Cookie差不多，只是Session是寫在服務(wù)器端的文件，也需要在客戶端寫入Cookie文件，但是文件里是用戶的瀏覽器編號.Session的狀態(tài)是存儲在服務(wù)器端，客戶端只有session id，而Token的狀態(tài)是存儲在客戶端的。

以上，是關(guān)于Token、Session、Cookie的知識點介紹，更加深入的詳解，感興趣的童鞋，可查看我持續(xù)分享的【BAT架構(gòu)技術(shù)專題合集500+】，回復(fù)【架構(gòu)】，即可領(lǐng)取。

如果覺得不錯，請點贊支持下~

session

session的中文翻譯是“會話”，當(dāng)用戶打開某個web應(yīng)用時，便與web服務(wù)器產(chǎn)生一次session。服務(wù)器使用session把用戶的信息臨時保存在了服務(wù)器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務(wù)器做了負(fù)載均衡，那么下一個操作請求到了另一臺服務(wù)器的時候session會丟失。

cookie

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

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設(shè)置為全局:\"\\")、失效時間、安全標(biāo)志(指定后，cookie只有在使用SSL連接時才發(fā)送到服務(wù)器(https))。下面是一個簡單的js使用cookie的例子:

用戶登錄時產(chǎn)生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\