關(guān)鍵詞：cookie session token
一与殃、什么是cookie
HTTP 是無狀態(tài)的協(xié)議（對于事務處理沒有記憶能力立帖，每次客戶端和服務端會話完成時眼溶，服務端不會保存任何會話信息）：每個請求都是完全獨立的，服務端無法確認當前訪問者的身份信息晓勇，無法分辨上一次的請求發(fā)送者和這一次的發(fā)送者是不是同一個人堂飞。所以服務器與瀏覽器為了進行會話跟蹤（知道是誰在訪問我），就必須主動的去維護一個狀態(tài)绑咱，這個狀態(tài)用于告知服務端前后兩個請求是否來自同一瀏覽器绰筛。而這個狀態(tài)需要通過 cookie 或者 session 去實現(xiàn)。
cookie 存儲在客戶端：cookie 是服務器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)描融，它會在瀏覽器下次向同一服務器再發(fā)起請求時被攜帶并發(fā)送到服務器上铝噩。
cookie 是不可跨域的：每個 cookie 都會綁定單一的域名，無法在別的域名下獲取使用窿克，一級域名和二級域名之間是允許共享使用的（靠的是 domain）骏庸。
cookie 重要的屬性：屬性說明name=value鍵值對，設(shè)置 Cookie 的名稱及相對應的值年叮，都必須是字符串類型
Cookie: _ga=GA1.2.379003058.1549525792; _gid=GA1.2.1638030012.1592105043; gr_user_id=d6451608-a020-4676-99b8-55d56bc3f9a3; QINGCLOUDELB=099339248b646d4bece12deee8f7545809f51ba16147f64a21f5d51a89fcd206|XuWYa|XuWYV; ab={}; gr_session_id_89669d96c88aefbc=987ec77f-7189-4da8-806c-524755eaea07; gr_session_id_89669d96c88aefbc_987ec77f-7189-4da8-806c-524755eaea07=true; Hm_lpvt_93bbd335a208870aa1f296bcd6842e5e=1592105043; Hm_lvt_93bbd335a208870aa1f296bcd6842e5e=1592105043; _gat=1
Set-Cookie: QINGCLOUDELB=ac47df2659e9aff9f6613b02d57715b500088fc926fa1aa3688c3252ebc222e8|XuWYa|XuWYa; path=/; HttpOnly
如果值為 Unicode 字符具被，需要為字符編碼。如果值為二進制數(shù)據(jù)谋右，則需要使用 BASE64 編碼硬猫。
domain指定 cookie 所屬域名，默認是當前域名.
path****指定 cookie 在哪個路徑（路由）下生效改执，默認是 '/'啸蜜。如果設(shè)置為/abc，則只有?/abc?下的路由可以訪問到該 cookie辈挂，如：/abc/read衬横。
maxAge ?cookie 失效的時間，單位秒终蒂。如果為整數(shù)蜂林，則該 cookie 在 maxAge 秒后失效遥诉。如果為負數(shù)，該 cookie 為臨時 cookie 噪叙，關(guān)閉瀏覽器即失效矮锈，瀏覽器也不會以任何形式保存該 cookie 。如果為 0睁蕾，表示刪除該 cookie 苞笨。默認為 -1。
比 expires 好用子眶。expires過期時間瀑凝，在設(shè)置的某個時間點后該 cookie 就會失效。一般瀏覽器的 cookie 都是默認儲存的臭杰，當關(guān)閉瀏覽器結(jié)束這個會話的時候粤咪，這個 cookie 也就會被刪除。
secure該 cookie 是否僅被使用安全協(xié)議傳輸渴杆。安全協(xié)議有 HTTPS寥枝，SSL等，在網(wǎng)絡(luò)上傳輸數(shù)據(jù)之前先將數(shù)據(jù)加密磁奖。默認為false脉顿。當 secure 值為 true 時实夹，cookie 在 HTTP 中是無效匙握，在 HTTPS 中才有效赊级。
httpOnly****如果給某個 cookie 設(shè)置了 httpOnly 屬性，則無法通過 JS 腳本 讀取到該 cookie 的信息敢辩，但還是能通過 Application 中手動修改 cookie，所以只是在一定程度上可以防止 XSS 攻擊弟疆，不是絕對的安全
二戚长、什么是session
session 是另一種記錄服務器和客戶端會話狀態(tài)的機制
session 是基于 cookie 實現(xiàn)的，session 存儲在服務器端怠苔，sessionId 會被存儲到客戶端的cookie 中
session 認證流程：
用戶第一次請求服務器的時候同廉，服務器根據(jù)用戶提交的相關(guān)信息，創(chuàng)建對應的 Session
請求返回時將此 Session 的唯一標識信息 SessionID 返回給瀏覽器
瀏覽器接收到服務器返回的 SessionID 信息后柑司，會將此信息存入到 Cookie 中迫肖，同時 Cookie 記錄此 SessionID 屬于哪個域名
當用戶第二次訪問服務器的時候，請求會自動判斷此域名下是否存在 Cookie 信息攒驰，如果存在自動將 Cookie 信息也發(fā)送給服務端蟆湖，服務端會從 Cookie 中獲取 SessionID，再根據(jù) SessionID 查找對應的 Session 信息玻粪，如果沒有找到說明用戶沒有登錄或者登錄失效隅津，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作诬垂。
根據(jù)以上流程可知，SessionID 是連接 Cookie 和 Session 的一道橋梁伦仍，大部分系統(tǒng)也是根據(jù)此原理來驗證用戶登錄狀態(tài)结窘。
cookie和session的區(qū)別
安全性：Session 比 Cookie 安全，Session 是存儲在服務器端的充蓝，Cookie 是存儲在客戶端的隧枫。
存取值的類型不同：Cookie 只支持存字符串數(shù)據(jù)，想要設(shè)置其他類型的數(shù)據(jù)棺克，需要將其轉(zhuǎn)換成字符串悠垛，Session 可以存任意數(shù)據(jù)類型。
有效期不同：Cookie 可設(shè)置為長時間保持娜谊，比如我們經(jīng)常使用的默認登錄功能确买，Session 一般失效時間較短，客戶端關(guān)閉（默認情況下）或者 Session 超時都會失效纱皆。
存儲大小不同：單個 Cookie 保存的數(shù)據(jù)不能超過 4K湾趾，Session 可存儲數(shù)據(jù)遠高于 Cookie，但是當訪問量過多派草，會占用過多的服務器資源搀缠。
三、什么是token
Acesss Token
訪問資源接口（API）時所需要的資源憑證
簡單 token 的組成：uid(用戶唯一的身份標識)近迁、time(當前時間的時間戳)艺普、sign（簽名，token 的前幾位以哈希算法壓縮成的一定長度的十六進制字符串）
特點：
服務端無狀態(tài)化鉴竭、可擴展性好
支持移動端設(shè)備
安全
支持跨程序調(diào)用
token 的身份驗證流程：
客戶端使用用戶名跟密碼請求登錄
服務端收到請求歧譬，去驗證用戶名與密碼
驗證成功后，服務端會簽發(fā)一個 token 并把這個 token 發(fā)送給客戶端
客戶端收到 token 以后搏存，會把它存儲起來瑰步，比如放在 cookie 里或者 localStorage 里
客戶端每次向服務端請求資源的時候需要帶著服務端簽發(fā)的 token
服務端收到請求，然后去驗證客戶端請求里面帶著的 token 璧眠，如果驗證成功缩焦，就向客戶端返回請求的數(shù)據(jù)
每一次請求都需要攜帶 token，需要把 token 放到 HTTP 的 Header 里
基于 token 的用戶認證是一種服務端無狀態(tài)的認證方式责静，服務端不用存放 token 數(shù)據(jù)袁滥。用解析 token 的計算時間換取 session 的存儲空間，從而減輕服務器的壓力泰演，減少頻繁的查詢數(shù)據(jù)庫
token 完全由應用管理呻拌，所以它可以避開同源策略
Refresh Token
另外一種 token——refresh token
refresh token 是專用于刷新 access token 的 token。如果沒有 refresh token睦焕，也可以刷新 access token藐握，但每次刷新都要用戶輸入登錄用戶名與密碼靴拱，會很麻煩。有了 refresh token猾普，可以減少這個麻煩袜炕，客戶端直接用 refresh token 去更新 access token，無需用戶進行額外的操作初家。
Access Token 的有效期比較短偎窘，當 Acesss Token 由于過期而失效時，使用 Refresh Token 就可以獲取到新的 Token溜在，如果 Refresh Token 也失效了陌知，用戶就只能重新登錄了。
Refresh Token 及過期時間是存儲在服務器的數(shù)據(jù)庫中掖肋，只有在申請新的 Acesss Token 時才會驗證仆葡，不會對業(yè)務接口響應時間造成影響，也不需要向 Session 一樣一直保持在內(nèi)存中以應對大量的請求志笼。
token和session的區(qū)別
Session 是一種記錄服務器和客戶端會話狀態(tài)的機制沿盅，使服務端有狀態(tài)化，可以記錄會話信息纫溃。而 Token 是令牌腰涧，訪問資源接口（API）時所需要的資源憑證。Token?使服務端無狀態(tài)化紊浩，不會存儲會話信息窖铡。
Session 和 Token 并不矛盾，作為身份認證 Token 安全性比 Session 好坊谁，因為每一個請求都有簽名還能防止監(jiān)聽以及重放攻擊万伤，而 Session 就必須依賴鏈路層來保障通訊安全了。如果你需要實現(xiàn)有狀態(tài)的會話呜袁，仍然可以增加 Session 來在服務器端保存一些狀態(tài)。
所謂 Session 認證只是簡單的把 User 信息存儲到 Session 里简珠，因為 SessionID 的不可預測性阶界，暫且認為是安全的。而 Token 聋庵，如果指的是 OAuth Token 或類似的機制的話膘融，提供的是 認證 和 授權(quán) ，認證是針對用戶祭玉，授權(quán)是針對 App 氧映。其目的是讓某 App 有權(quán)利訪問某用戶的信息。這里的 Token 是唯一的脱货。不可以轉(zhuǎn)移到其它 App上岛都，也不可以轉(zhuǎn)到其它用戶上律姨。Session 只提供一種簡單的認證，即只要有此 SessionID 臼疫，即認為有此 User 的全部權(quán)利择份。是需要嚴格保密的，這個數(shù)據(jù)應該只保存在站方烫堤，不應該共享給其它網(wǎng)站或者第三方 App荣赶。所以簡單來說：如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用 API 接口鸽斟，用 Token 拔创。如果永遠只是自己的網(wǎng)站，自己的 App富蓄，用什么就無所謂了剩燥。
四、常見問題
使用 cookie 時需要考慮的問題
因為存儲在客戶端格粪，容易被客戶端篡改躏吊，使用前需要驗證合法性
不要存儲敏感數(shù)據(jù)，比如用戶密碼帐萎，賬戶余額
使用 httpOnly 在一定程度上提高安全性
盡量減少 cookie 的體積比伏，能存儲的數(shù)據(jù)量不能超過 4kb
設(shè)置正確的 domain 和 path，減少數(shù)據(jù)傳輸
cookie 無法跨域
一個瀏覽器針對一個網(wǎng)站最多存 20 個Cookie疆导，瀏覽器一般只允許存放 300 個Cookie
移動端對 cookie 的支持不是很好赁项，而 session 需要基于 cookie 實現(xiàn)，所以移動端常用的是 token
使用 session 時需要考慮的問題
將 session 存儲在服務器里面澈段，當用戶同時在線量比較多時悠菜，這些 session 會占據(jù)較多的內(nèi)存，需要在服務端定期的去清理過期的 session
當網(wǎng)站采用集群部署的時候败富，會遇到多臺 web 服務器之間如何做 session 共享的問題悔醋。因為 session 是由單個服務器創(chuàng)建的，但是處理用戶請求的服務器不一定是那個創(chuàng)建 session 的服務器兽叮，那么該服務器就無法拿到之前已經(jīng)放入到 session 中的登錄憑證之類的信息了芬骄。
當多個應用要共享 session 時，除了以上問題鹦聪，還會遇到跨域問題账阻，因為不同的應用可能部署的主機不一樣，需要在各個應用做好 cookie 跨域的處理泽本。
sessionId 是存儲在 cookie 中的淘太，假如瀏覽器禁止 cookie 或不支持 cookie 怎么辦？一般會把 sessionId 跟在 url 參數(shù)后面即重寫 url，所以 session 不一定非得需要靠 cookie 實現(xiàn)
移動端對 cookie 的支持不是很好蒲牧，而 session 需要基于 cookie 實現(xiàn)撇贺，所以移動端常用的是 token
使用 token 時需要考慮的問題
如果你認為用數(shù)據(jù)庫來存儲 token 會導致查詢時間太長，可以選擇放在內(nèi)存當中造成。比如 redis 很適合你對 token 查詢的需求显熏。
token 完全由應用管理，所以它可以避開同源策略
token 可以避免 CSRF 攻擊(因為不需要 cookie 了)
移動端對 cookie 的支持不是很好晒屎，而 session 需要基于 cookie 實現(xiàn)喘蟆，所以移動端常用的是 token
使用 JWT 時需要考慮的問題
因為 JWT 并不依賴 Cookie 的，所以你可以使用任何域名提供你的 API 服務而不需要擔心跨域資源共享問題（CORS）
JWT 默認是不加密鼓鲁，但也是可以加密的蕴轨。生成原始 Token 以后，可以用密鑰再加密一次骇吭。
JWT 不加密的情況下橙弱，不能將秘密數(shù)據(jù)寫入 JWT。
JWT 不僅可以用于認證燥狰，也可以用于交換信息棘脐。有效使用 JWT，可以降低服務器查詢數(shù)據(jù)庫的次數(shù)龙致。
JWT 最大的優(yōu)勢是服務器不再需要存儲 Session蛀缝，使得服務器認證鑒權(quán)業(yè)務可以方便擴展。但這也是 JWT 最大的缺點：由于服務器不需要存儲 Session 狀態(tài)目代，因此使用過程中無法廢棄某個 Token 或者更改 Token 的權(quán)限屈梁。也就是說一旦 JWT 簽發(fā)了，到期之前就會始終有效榛了，除非服務器部署額外的邏輯在讶。
JWT 本身包含了認證信息，一旦泄露霜大，任何人都可以獲得該令牌的所有權(quán)限构哺。為了減少盜用，JWT的有效期應該設(shè)置得比較短战坤。對于一些比較重要的權(quán)限遮婶，使用時應該再次對用戶進行認證。
JWT 適合一次性的命令認證湖笨，頒發(fā)一個有效期極短的 JWT，即使暴露了危險也很小蹦骑，由于每次操作都會生成新的 JWT慈省，因此也沒必要保存 JWT，真正實現(xiàn)無狀態(tài)。
為了減少盜用边败，JWT 不應該使用 HTTP 協(xié)議明碼傳輸袱衷，要使用 HTTPS 協(xié)議傳輸。
使用加密算法時需要考慮的問題
絕不要以明文存儲密碼
永遠使用 哈希算法 來處理密碼笑窜，絕不要使用 Base64 或其他編碼方式來存儲密碼致燥，這和以明文存儲密碼是一樣的，使用哈希排截，而不要使用編碼嫌蚤。編碼以及加密，都是雙向的過程断傲，而密碼是保密的脱吱，應該只被它的所有者知道， 這個過程必須是單向的认罩。哈希正是用于做這個的箱蝠，從來沒有解哈希這種說法， 但是編碼就存在解碼垦垂，加密就存在解密宦搬。
絕不要使用弱哈希或已被破解的哈希算法劫拗，像 MD5 或 SHA1 间校，只使用強密碼哈希算法。
絕不要以明文形式顯示或發(fā)送密碼杨幼，即使是對密碼的所有者也應該這樣撇簿。如果你需要 “忘記密碼” 的功能，可以隨機生成一個新的一次性的（這點很重要）密碼差购，然后把這個密碼發(fā)送給用戶四瘫。
分布式架構(gòu)下 session 共享方案
1. session 復制
任何一個服務器上的 session 發(fā)生改變（增刪改），該節(jié)點會把這個 session 的所有內(nèi)容序列化欲逃，然后廣播給所有其它節(jié)點找蜜，不管其他服務器需不需要 session ，以此來保證 session 同步
優(yōu)點：可容錯稳析，各個服務器間 session 能夠?qū)崟r響應洗做。
缺點：會對網(wǎng)絡(luò)負荷造成一定壓力，如果 session 量大的話可能會造成網(wǎng)絡(luò)堵塞彰居，拖慢服務器性能诚纸。
2. 粘性 session /IP 綁定策略
采用 Ngnix 中的 ip_hash 機制，將某個 ip的所有請求都定向到同一臺服務器上陈惰，即將用戶與服務器綁定畦徘。用戶第一次請求時，負載均衡器將用戶的請求轉(zhuǎn)發(fā)到了 A 服務器上，如果負載均衡器設(shè)置了粘性 session 的話井辆，那么用戶以后的每次請求都會轉(zhuǎn)發(fā)到 A 服務器上关筒，相當于把用戶和 A 服務器粘到了一塊，這就是粘性 session 機制杯缺。
優(yōu)點：簡單蒸播，不需要對 session 做任何處理。
缺點：缺乏容錯性萍肆，如果當前訪問的服務器發(fā)生故障袍榆，用戶被轉(zhuǎn)移到第二個服務器上時，他的 session 信息都將失效匾鸥。
適用場景：發(fā)生故障對客戶產(chǎn)生的影響較欣；服務器發(fā)生故障是低概率事件勿负。實現(xiàn)方式：以 Nginx 為例馏艾，在 upstream 模塊配置 ip_hash 屬性即可實現(xiàn)粘性 session。
3. session 共享（常用）
使用分布式緩存方案比如 Memcached 奴愉、Redis 來緩存 session琅摩，但是要求 Memcached 或 Redis 必須是集群
把 session 放到 Redis 中存儲，雖然架構(gòu)上變得復雜锭硼，并且需要多訪問一次 Redis 房资，但是這種方案帶來的好處也是很大的：
實現(xiàn)了 session 共享；
可以水平擴展（增加 Redis 服務器）檀头；
服務器重啟 session 不丟失（不過也要注意 session 在 Redis 中的刷新/失效機制）轰异；
不僅可以跨服務器 session 共享，甚至可以跨平臺（例如網(wǎng)頁端和 APP 端）
4. session 持久化
將 session 存儲到數(shù)據(jù)庫中暑始，保證 session 的持久化
優(yōu)點：服務器出現(xiàn)問題搭独，session 不會丟失
缺點：如果網(wǎng)站的訪問量很大，把 session 存儲到數(shù)據(jù)庫中廊镜，會對數(shù)據(jù)庫造成很大壓力牙肝，還需要增加額外的開銷維護數(shù)據(jù)庫。
只要關(guān)閉瀏覽器 嗤朴，session 真的就消失了配椭？
不對。對 session 來說雹姊，除非程序通知服務器刪除一個 session股缸，否則服務器會一直保留，程序一般都是在用戶做 log off 的時候發(fā)個指令去刪除 session吱雏。然而瀏覽器從來不會主動在關(guān)閉之前通知服務器它將要關(guān)閉敦姻，因此服務器根本不會有機會知道瀏覽器已經(jīng)關(guān)閉寺酪，之所以會有這種錯覺，是大部分 session 機制都使用會話 cookie 來保存 session id替劈，而關(guān)閉瀏覽器后這個 session id 就消失了，再次連接服務器時也就無法找到原來的 session得滤。如果服務器設(shè)置的 cookie 被保存在硬盤上陨献，或者使用某種手段改寫瀏覽器發(fā)出的 HTTP 請求頭，把原來的 session id 發(fā)送給服務器懂更，則再次打開瀏覽器仍然能夠打開原來的 session眨业。恰恰是由于關(guān)閉瀏覽器不會導致 session 被刪除，迫使服務器為 session 設(shè)置了一個失效時間沮协，當距離客戶端上一次使用 session 的時間超過這個失效時間時龄捡，服務器就認為客戶端已經(jīng)停止了活動，才會把 session 刪除以節(jié)省存儲空間慷暂。
備注：JSON Web Token（簡稱 JWT）是目前最流行的跨域認證解決方案聘殖。
參考：
