HTTP 是無狀態的，全部的請求都是無狀態的。然而，某些情況下我們想讓我們的狀態能被記住。比如，瀏覽一家在線商店，當我們把香蕉放到購物車中后，再去其他頁面購買蘋果時，並不希望我們的香蕉消失。在在線商店的各個頁面中穿梭時，我們是希望想我們的購買狀態是能夠被記住的！
為了克服 HTTP 請求無狀態的性質，我們可以使用 session 或者 token。簡單來說有兩種方式可以記住用戶的狀態
session和token都是用來保持會話，功能相同。
基於 Session
基於 session 的認證中，用戶登錄后服務器會為登錄用戶創建一個 session，Cookie的驗證是有狀態的，sessionid 會保存在用戶瀏覽器的 cookie 中。當用戶登錄成功后，cookie 會隨着后邊的每個請求一起發送。這樣，服務器通過 cookie 中的 sessionid 找到內存中的 session 數據，來驗證用戶身份，從而在響應中返回相應的狀態。
1.客戶端發送一個http請求帶着用戶名密碼到服務器端
2.服務器端接受了客戶端請求后，建立一個session，並發送一個http響應到客戶端，這個響應頭包括了set-cookie的頭部，頭部里面包括了sessionid
set-cookie的格式如下 Set-Cookie:value [ ;expire=date ][ ;damain=domain ][ ;path=path ][ ;secure ]
3.客戶端發起第二次請求，服務器已經給了setcookie，瀏覽器自動在請求頭上獲取到cookie並分解 驗證信息成功后返回respense給客戶端
session的弊端：
- session是服務端存儲的一個對象，主要用來存儲所有訪問過該服務端的客戶端的用戶信息（也可以存儲其他信息），從而實現保持用戶會話狀態。但是服務器重啟時，內存會被銷毀，存儲的用戶信息也就消失了。
不同的用戶訪問服務端的時候會在session對象中存儲鍵值對，“鍵”用來存儲開啟這個用戶信息的“鑰匙”，在登錄成功后，“鑰匙”通過cookie返回給客戶端，客戶端存儲為sessionId記錄在cookie中。當客戶端再次訪問時，會默認攜帶cookie中的sessionId來實現會話機制。
- session是基於cookie的。
- cookie的數據4k左右
- cookie存儲數據的格式：字符串key=value
- cookie存儲有效期：可以自行通過expires進行具體的日期設置，如果沒設置，默認是關閉瀏覽器時失效。
- cookie有效范圍：當前域名下有效。所以session這種會話存儲方式方式只適用於客戶端代碼和服務端代碼運行在同一台服務器上（前后端項目協議、域名、端口號都一致，即在一個項目下）
- session持久化
用於解決重啟服務器后session就消失的問題。在數據庫中存儲session，而不是存儲在內存中。通過包：express-mysql-session
- 其它
當客戶端存儲的cookie失效后，服務端的session不會立即銷毀，會有一個延時，服務端會定期清理無效session，不會造成無效數據占用存儲空間的問題。
基於 Token
很多網絡應用使用 json web token 也即 JWT 來代替 session 實現身份認證。在這種基於 token 的應用中，服務器使用一個密鑰來創建 jwt 並發送給客戶端。客戶端會保存此 jwt（通常保存在本地存儲 local storage 中）並在每個請求的 header 中包含此 jwt。服務器驗證客戶端發來的每個請求中的 jwt ,做出響應。 token 的驗證是無狀態的，存儲在 Authorization Header 中進行驗證，形式是Bear{ JWT }
它與 session 方式最大的不同是用戶狀態不存儲在服務器端，而是存儲在 token 中並保存在客戶端。為了擴展性，大部分現代網絡應用都使用 jwt 來進行用戶認證。
token的組成一般是 uid（用戶唯一身份標識）+time（時間戳）+sign（簽名使用hash壓縮成固長的十六進制字符串 防止第三方惡意拼接）+固定參數可選
1.用戶登錄，成功后服務器返回Token給客戶端
2.客戶端收到數據后保存在客戶端
3.客戶端再次訪問服務器，將token放header中
4.服務器采用filter進行過濾校驗，成功返回請求數據，校驗失敗返回錯誤碼
- 適用於項目級的前后端分離（前后端代碼運行在不同的服務器下）
請求登錄時，token和sessionId原理相同，是對key和key對應的用戶信息進行加密后的加密字符，登錄成功后，會在響應主體中將{token：'字符串'}返回給客戶端。客戶端通過cookie、sessionStorage、localStorage都可以進行存儲。再次請求時不會默認攜帶，需要在請求攔截器位置給請求頭中添加認證字段Authorization攜帶token信息，服務器端就可以通過token信息查找用戶登錄狀態。
擴展性
基於 session: 由於 session 存儲於服務器端（一般是內存型數據庫，如 redis），當用戶量很大時會有一定的擴展性問題。
基於 token: 存儲在客戶端，不存在上邊這個問題。
token可以抵抗csrf（跨域請求偽造），更安全，使用cookie在post請求的同時會自動添加到請求頭上，token則不會自動添加到請求頭中，
攻擊者也無法訪問用戶的token，無法形成攻擊。
多設備
基於 session: cookie 通常工作在單個域名或其子域名下，而且跨域名時通常會被瀏覽器關閉。當 API 要服務於不同域名的移動和網絡設備時，容易出現問題。
基於 token: 由於 jwt 包含於請求頭當中，不存在 cookie 引發的相關的問題。
翻譯自：Session vs Token Based Authentication
關於 jwt 的更多信息，可以參考阮一峰的文章《Json Web Token 入門教程》
***********************************************************************************************************************************************************************
很久很久以前，Web 基本上就是文檔的瀏覽而已， 既然是瀏覽，作為服務器， 不需要記錄誰在某一段時間里都瀏覽了什么文檔。
發展史
1、很久很久以前，Web 基本上就是文檔的瀏覽而已， 既然是瀏覽，作為服務器， 不需要記錄誰在某一段時間里都瀏覽了什么文檔。
每次請求都是一個新的HTTP協議， 就是請求加響應，尤其是我不用記住是誰剛剛發了HTTP請求，每個請求對我來說都是全新的。這段時間很嗨皮。
2、但是隨着交互式Web應用的興起，像在線購物網站，需要登錄的網站等等，馬上就面臨一個問題，那就是要管理會話，必須記住哪些人登錄系統，哪些人往自己的購物車中放商品。
也就是說我必須把每個人區分開，這就是一個不小的挑戰，因為HTTP請求是無狀態的，所以想出的辦法就是給大家發一個會話標識(session id)。
說白了就是一個隨機的字串，每個人收到的都不一樣，每次大家向我發起HTTP請求的時候，把這個字符串給一並捎過來，這樣我就能區分開誰是誰了。
3、這樣大家很嗨皮了，可是服務器就不嗨皮了，每個人只需要保存自己的session id，而服務器要保存所有人的session id 。如果訪問服務器多了，就得由成千上萬，甚至幾十萬個。
這對服務器來說是一個巨大的開銷 ， 嚴重的限制了服務器擴展能力。
比如說我用兩個機器組成了一個集群，小F通過機器A登錄了系統，那session id會保存在機器A上，假設小F的下一次請求被轉發到機器B怎么辦?機器B可沒有小F的 session id啊。
有時候會采用一點小伎倆：session sticky ，就是讓小F的請求一直粘連在機器A上，但是這也不管用， 要是機器A掛掉了， 還得轉到機器B去。
那只好做session 的復制了， 把session id 在兩個機器之間搬來搬去， 快累死了。
后來有個叫Memcached的支了招：把session id 集中存儲到一個地方，所有的機器都來訪問這個地方的數據。
這樣一來，就不用復制了，但是增加了單點失敗的可能性，要是那個負責session 的機器掛了，所有人都得重新登錄一遍，估計得被人罵死。
也嘗試把這個單點的機器也搞出集群，增加可靠性，但不管如何，這小小的session 對我來說是一個沉重的負擔。 4、於是有人就一直在思考，我為什么要保存這可惡的session呢，只讓每個客戶端去保存該多好? 可是如果不保存這些session id ，怎么驗證客戶端發給我的session id 的確是我生成的呢?
如果不去驗證，我們都不知道他們是不是合法登錄的用戶，那些不懷好意的家伙們就可以偽造session id，為所欲為了。 嗯，對了，關鍵點就是驗證 ! 比如說，小F已經登錄了系統，我給他發一個令牌(token)，里邊包含了小F的 user id，下一次小F 再次通過Http 請求訪問我的時候，把這個token 通過Http header 帶過來不就可以了。 不過這和session id沒有本質區別啊，任何人都可以可以偽造，所以我得想點兒辦法，讓別人偽造不了。
那就對數據做一個簽名吧，比如說我用HMAC-SHA256 算法，加上一個只有我才知道的密鑰，對數據做一個簽名，把這個簽名和數據一起作為token，由於密鑰別人不知道，就無法偽造token了。
這個token 我不保存，當小F把這個token 給我發過來的時候，我再用同樣的HMAC-SHA256 算法和同樣的密鑰，對數據再計算一次簽名，和token 中的簽名做個比較，如果相同，我就知道小F已經登錄過了，並且可以直接取到小F的user id，如果不相同，數據部分肯定被人篡改過，我就告訴發送者：對不起，沒有認證。
Token 中的數據是明文保存的(雖然我會用Base64做下編碼， 但那不是加密)，還是可以被別人看到的，所以我不能在其中保存像密碼這樣的敏感信息。
當然，如果一個人的token 被別人偷走了，那我也沒辦法，我也會認為小偷就是合法用戶，這其實和一個人的session id 被別人偷走是一樣的。 這樣一來，我就不保存session id 了，我只是生成token ，然后驗證token ，我用我的CPU計算時間獲取了我的session 存儲空間 ! 解除了session id這個負擔，可以說是無事一身輕，我的機器集群現在可以輕松地做水平擴展，用戶訪問量增大，直接加機器就行。這種無狀態的感覺實在是太好了!
Cookie
cookie 是一個非常具體的東西，指的就是瀏覽器里面能永久存儲的一種數據，僅僅是瀏覽器實現的一種數據存儲功能。
cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。
由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據太多磁盤空間，所以每個域的cookie數量是有限的。
Session
session 從字面上講，就是會話。這個就類似於你和一個人交談，你怎么知道當前和你交談的是張三而不是李四呢?對方肯定有某種特征(長相等)表明他就是張三。
session 也是類似的道理，服務器要知道當前發請求給自己的是誰。
為了做這種區分，服務器就要給每個客戶端分配不同的“身份標識”，然后客戶端每次向服務器發請求的時候，都帶上這個“身份標識”，服務器就知道這個請求來自於誰了。
至於客戶端怎么保存這個“身份標識”，可以有很多種方式，對於瀏覽器客戶端，大家都默認采用 cookie 的方式。
服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站后session會被銷毀。
這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一台服務器的時候session會丟失。
Token
在Web領域基於Token的身份驗證隨處可見。在大多數使用Web API的互聯網公司中，tokens 是多用戶下處理認證的最佳方式。
以下幾點特性會讓你在程序中使用基於Token的身份驗證：
- 無狀態、可擴展
- 支持移動設備
- 跨程序調用
- 安全
那些使用基於Token的身份驗證的大佬們
大部分你見到過的API和Web應用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
Token的起源
在介紹基於Token的身份驗證的原理與優勢之前，不妨先看看之前的認證都是怎么做的。
基於服務器的驗證
我們都是知道HTTP協議是無狀態的，這種無狀態意味着程序需要驗證每一次請求，從而辨別客戶端的身份。
在這之前，程序都是通過在服務端存儲的登錄信息來辨別請求的。這種方式一般都是通過存儲Session來完成。 隨着Web，應用程序，已經移動端的興起，這種驗證的方式逐漸暴露出了問題。尤其是在可擴展性方面。
基於服務器驗證方式暴露的一些問題
1. Seesion：每次認證用戶發起請求時，服務器需要去創建一個記錄來存儲信息。當越來越多的用戶發請求時，內存的開銷也會不斷增加。
2. 可擴展性：在服務端的內存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。
3. CORS(跨域資源共享)：當我們需要讓數據跨多台移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。
4. CSRF(跨站請求偽造)：用戶在訪問銀行網站時，他們很容易受到跨站請求偽造的攻擊，並且能夠被利用其訪問其他的網站。
在這些問題中，可擴展行是最突出的。因此我們有必要去尋求一種更有行之有效的方法。
基於Token的驗證原理
基於Token的身份驗證是無狀態的，我們不將用戶信息存在服務器或Session中。
這種概念解決了在服務端存儲信息時的許多問題。
NoSession意味着你的程序可以根據需要去增減機器，而不用去擔心用戶是否登錄。
基於Token的身份驗證的過程如下:
- 用戶通過用戶名和密碼發送請求。
- 程序驗證。
- 程序返回一個簽名的token 給客戶端。
- 客戶端儲存token,並且每次用於每次發送請求。
- 服務端驗證token並返回數據。
每一次請求都需要token。token應該在HTTP的頭部發送從而保證了Http請求無狀態。
我們同樣通過設置服務器屬性Access-Control-Allow-Origin:* ，讓服務器能接受到來自所有域的請求。
需要注意的是，在ACAO頭部標明(designating)*時，不得帶有像HTTP認證，客戶端SSL證書和cookies的證書。
實現思路：
1. 用戶登錄校驗，校驗成功后就返回Token給客戶端。
2. 客戶端收到數據后保存在客戶端
3. 客戶端每次訪問API是攜帶Token到服務器端。
4. 服務器端采用filter過濾器校驗。校驗成功則返回請求數據，校驗失敗則返回錯誤碼。 當我們在程序中認證了信息並取得token之后，我們便能通過這個Token做許多的事情。
我們甚至能基於創建一個基於權限的token傳給第三方應用程序，這些第三方程序能夠獲取到我們的數據(當然只有在我們允許的特定的token)。
Tokens的優勢
無狀態、可擴展
在客戶端存儲的Tokens是無狀態的，並且能夠被擴展。基於這種無狀態和不存儲Session信息，負載負載均衡器能夠將用戶信息從一個服務傳到其他服務器上。
如果我們將已驗證的用戶的信息保存在Session中，則每次請求都需要用戶向已驗證的服務器發送驗證信息(稱為Session親和性)。用戶量大時，可能會造成一些擁堵。
但是不要着急。使用tokens之后這些問題都迎刃而解，因為tokens自己hold住了用戶的驗證信息。
安全性
請求中發送token而不再是發送cookie能夠防止CSRF(跨站請求偽造)。
即使在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用於認證。不將信息存儲在Session中，讓我們少了對session操作。
token是有時效的，一段時間之后用戶需要重新驗證。我們也不一定需要等到token自動失效，token有撤回的操作，通過token revocataion可以使一個特定的token或是一組有相同認證的token無效。
可擴展性
Tokens能夠創建與其它程序共享權限的程序。
例如，能將一個隨便的社交帳號和自己的大號(Fackbook或是Twitter)聯系起來。
當通過服務登錄Twitter(我們將這個過程Buffer)時，我們可以將這些Buffer附到Twitter的數據流上(we are allowing Buffer to post to our Twitter stream)。
使用tokens時，可以提供可選的權限給第三方應用程序。當用戶想讓另一個應用程序訪問它們的數據，我們可以通過建立自己的API，得出特殊權限的tokens。
多平台跨域
我們提前先來談論一下CORS(跨域資源共享)，對應用程序和服務進行擴展的時候，需要介入各種各種的設備和應用程序。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
只要用戶有一個通過了驗證的token，數據和資源就能夠在任何域上被請求到。
基於標准創建token的時候，你可以設定一些選項。我們在后續的文章中會進行更加詳盡的描述，但是標准的用法會在JSON Web Tokens體現。
最近的程序和文檔是供給JSON Web Tokens的。它支持眾多的語言。這意味在未來的使用中你可以真正的轉換你的認證機制。
參考文檔
https://network.51cto.com/art/201911/605549.htm
********************************************************************************************
Cookie和Session的區別：
1、cookie數據由服務端生成發送存放在客戶的瀏覽器上，session數據放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙,考慮到安全應當使用session。
3、session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能,考慮到減輕服務器性能方面，應當使用cookie。
4、數據格式是鍵值對，單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、cookie數據過期機制是設置expire值
6、所以個人建議：
將登陸信息等重要信息存放為session
其他信息如果需要保留，可以放在cookie中
cookie有很多使用場景，在項目中比較常見的有：
1.登錄記住用戶名
2.記錄用戶瀏覽記錄
Token 和 Session 的區別：
session和 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的狀態是存儲在客戶端。
Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。 如果說Cookie機制是通過檢查客戶身上的“通行證”來確定客戶身份的話，那么Session機制就是通過檢查服務器上的“客戶明細表”來確認客戶身份。Session相當於程序在服務器上建立的一份客戶檔案，客戶來訪的時候只需要查詢客戶檔案表就可以了