做Web開發(fā)的早晚會(huì)遇到這么一關(guān)登錄狀態(tài)到底該怎么存翻了一圈資料Cookie、Session、Token各說各話有的說Session安全有的說Token跨域方便還有人說Cookie早就該被淘汰了。尤其剛接觸前后端聯(lián)調(diào)或者自己寫登錄注冊(cè)功能的時(shí)候這三個(gè)概念經(jīng)常攪在一起接口調(diào)不通還以為是后端代碼寫錯(cuò)了其實(shí)問題的根源全在認(rèn)證機(jī)制的理解上。我當(dāng)年也被這東西繞暈過后來在真實(shí)項(xiàng)目里跌跌撞撞踩了一圈坑才把這塊徹底理清楚。說句大實(shí)話這仨不是一個(gè)層面的東西它們之間的關(guān)系更像是“容器—存儲(chǔ)—憑證”的分工協(xié)作而不是三個(gè)互相對(duì)立的方案。這篇文章我不講什么高深理論就用大白話把它們的來龍去脈、底層邏輯、實(shí)際使用場(chǎng)景和真實(shí)項(xiàng)目里的坑一次說透保證你看完能馬上動(dòng)手在自己項(xiàng)目里做取舍。1. 三者本質(zhì)先弄清它們分別解決什么問題1.1 從HTTP的無狀態(tài)聊起HTTP協(xié)議本身是“無狀態(tài)”的意思是服務(wù)器每次收到請(qǐng)求都像個(gè)失憶的人它不知道這次請(qǐng)求是不是你上次剛進(jìn)來的那個(gè)人。你登錄成功之后刷新一下頁面按理說服務(wù)器應(yīng)該記得你是誰但HTTP協(xié)議天生沒這個(gè)記憶能力。這時(shí)候就需要有一種機(jī)制讓服務(wù)器“認(rèn)出你”。你說簡(jiǎn)單啊那每次請(qǐng)求都帶上用戶名和密碼不就行了行倒是行但每次都要明文傳密碼既不安全也極其浪費(fèi)。于是人們就設(shè)計(jì)了各種更聰明的方案核心目標(biāo)就一個(gè)讓你第一次證明過身份之后后面每次請(qǐng)求都能輕量地證明“我就是我”。這就像進(jìn)健身房第一次辦了卡前臺(tái)把你信息登記了給你一把儲(chǔ)物柜鑰匙。以后每次來你晃一下鑰匙就行不用重新跟人家復(fù)述一遍姓名、電話、身份證號(hào)。Cookie、Session、Token本質(zhì)上都是在扮演這把鑰匙區(qū)別只在于鑰匙的樣子、存鑰匙的地方以及健身房前臺(tái)記不記得住你。1.2 一個(gè)健身房類比看懂三者的協(xié)作關(guān)系我見過很多初學(xué)者上來就搞混Cookie和Session誰包含誰其實(shí)完全可以拿健身房這個(gè)例子硬套Cookie是你掛在手上的鑰匙牌瀏覽器負(fù)責(zé)保管每次你走到健身房門口發(fā)請(qǐng)求給服務(wù)器它會(huì)自動(dòng)把鑰匙牌遞過去。Session是健身房前臺(tái)手里的儲(chǔ)物柜登記冊(cè)上面寫著“鑰匙牌號(hào)為A001的人名字叫小明辦了年卡”。這個(gè)登記冊(cè)放在服務(wù)端服務(wù)器每次看到鑰匙牌號(hào)就去翻登記冊(cè)。Token是你手機(jī)上的電子通行證上面印著“本人小明年卡會(huì)員有效期到年底”還帶一個(gè)防偽簽名。健身房大門只需要驗(yàn)一下簽名真?zhèn)尉湍苤苯臃拍氵M(jìn)去前臺(tái)完全不用翻登記冊(cè)。所以你說三者是對(duì)立關(guān)系嗎不是。Session幾乎總是配合Cookie一起用因?yàn)镾ession本身只負(fù)責(zé)在服務(wù)端存數(shù)據(jù)它需要一種方式把那個(gè)“會(huì)話標(biāo)識(shí)”送到瀏覽器再帶回來——Cookie剛好就是最現(xiàn)成的搬運(yùn)工。Token則更像一張自帶信息的通行證可以把Session里的“登記冊(cè)”部分整個(gè)干掉但它的驗(yàn)證環(huán)節(jié)需要簽名算法來支撐。1.3 三個(gè)最常被問到的核心差異這三個(gè)概念傻傻分不清本質(zhì)上是因?yàn)榻?jīng)常有人在不同的層面進(jìn)行比較。我?guī)湍惆阉鸪扇齻€(gè)最核心的問題第一個(gè)問題狀態(tài)到底存在哪Cookie存在瀏覽器本地Session存在服務(wù)端Token也大部分存在客戶端但Token更特殊——它把“你是誰、你有什么權(quán)限”這些信息直接編碼在憑證本身里。第二個(gè)問題服務(wù)器怎么驗(yàn)證你Cookie時(shí)代服務(wù)器讀到Cookie里的內(nèi)容就能拿到身份信息Session時(shí)代服務(wù)器必須先拿著會(huì)話ID去查存儲(chǔ)查到了才知道你是誰Token時(shí)代服務(wù)器不需要查任何存儲(chǔ)直接驗(yàn)簽就能確認(rèn)憑證真假。第三個(gè)問題丟失了會(huì)怎樣Cookie丟了如果里面存了身份信息別人撿到就能冒充Session標(biāo)識(shí)丟了因?yàn)榉?wù)端登記冊(cè)還在只要設(shè)置合理風(fēng)險(xiǎn)通?？煽豑oken丟了由于服務(wù)端不保存狀態(tài)、無法主動(dòng)讓你這個(gè)Token失效危險(xiǎn)期會(huì)一直延續(xù)到它過期為止。理解了這三條后面再看技術(shù)細(xì)節(jié)就不會(huì)亂了。2. Cookie細(xì)節(jié)深入不僅僅是“瀏覽器小餅干”2.1 Cookie的完整工作機(jī)制Cookie是服務(wù)器通過HTTP響應(yīng)頭種到瀏覽器里的一個(gè)小型文本片段瀏覽器拿到之后會(huì)按域名、路徑、過期時(shí)間等規(guī)則存起來之后每次向該域名發(fā)請(qǐng)求都會(huì)自動(dòng)帶上匹配的Cookie。用一個(gè)最直觀的例子用任何后端語言都只是換個(gè)寫法本質(zhì)都是設(shè)置這個(gè)響應(yīng)頭Set-Cookie: sessionIdabc123xyz; ExpiresWed, 02 Nov 2026 08:00:00 GMT; Path/; HttpOnly; Secure; SameSiteLax瀏覽器收到這個(gè)響應(yīng)頭之后會(huì)在本地記錄一條Cookie鍵是sessionId值是abc123xyz域名是當(dāng)前請(qǐng)求的域名路徑限制是/過期時(shí)間是2026年11月2日。之后你再去訪問該域名下的任何頁面請(qǐng)求頭里都會(huì)帶上Cookie: sessionIdabc123xyz服務(wù)器從請(qǐng)求頭里解析出這個(gè)Cookie就知道“哦是abc123xyz這個(gè)會(huì)話”。2.2 每個(gè)屬性都要弄明白的工程細(xì)節(jié)我見過大量Cookie相關(guān)bug幾乎都是某個(gè)屬性寫錯(cuò)了導(dǎo)致的。這里把幾個(gè)重要屬性逐一拆開講Expires與Max-AgeExpires指定一個(gè)絕對(duì)的過期時(shí)間點(diǎn)Max-Age指定從設(shè)置時(shí)刻起相對(duì)存活多少秒?，F(xiàn)代瀏覽器以Max-Age優(yōu)先。如果你兩個(gè)都不設(shè)置那這個(gè)Cookie就是會(huì)話級(jí)Cookie瀏覽器一關(guān)就沒了。很多“為什么下次打開還要重新登錄”的排查方向就在這里因?yàn)槟惴N下的可能是個(gè)沒設(shè)過期時(shí)間的會(huì)話Cookie。Domain決定Cookie要送到哪個(gè)域名。默認(rèn)情況下只發(fā)給設(shè)置它的那個(gè)域名但如果你設(shè)置了Domainexample.com那它的所有子域比如www.example.com、api.example.com都會(huì)收到。反過來跨域請(qǐng)求時(shí)前端反復(fù)跟你抱怨“為什么沒有Cookie”八成就是Domain規(guī)則沒搞對(duì)。Path路徑限制控制哪些路徑下發(fā)送。一般設(shè)成/最省心但如果你的接口里有些路徑不需要帶認(rèn)證信息設(shè)了Path之后可以減少無謂的傳輸。HttpOnly這個(gè)屬性極其重要。設(shè)置之后瀏覽器禁止JavaScript腳本通過document.cookie去讀取這個(gè)Cookie。這樣即便頁面里被注入了惡意腳本攻擊者也偷不走你的會(huì)話憑證。我強(qiáng)烈建議任何跟身份認(rèn)證有關(guān)的Cookie都必須加HttpOnly這是對(duì)抗XSS跨站腳本攻擊的第一道防線。Secure要求只在HTTPS連接下才會(huì)發(fā)送這個(gè)Cookie。生產(chǎn)環(huán)境必須開不然在Wi-Fi環(huán)境下中間人攻擊者裸奔在網(wǎng)絡(luò)上就能抓到你的Cookie。SameSite這是應(yīng)對(duì)CSRF跨站請(qǐng)求偽造的關(guān)鍵武器。Strict表示跨站請(qǐng)求一律不帶CookieLax表示跨站場(chǎng)景下只有頂級(jí)導(dǎo)航比如你從郵件點(diǎn)鏈接跳轉(zhuǎn)到該網(wǎng)站才帶Cookie一般子資源請(qǐng)求、跨站AJAX都不帶None表示任何場(chǎng)景都帶但前提是必須同時(shí)設(shè)置有Secure屬性。現(xiàn)在主流瀏覽器默認(rèn)SameSite就是Lax這也是為什么很多舊系統(tǒng)升級(jí)到新版瀏覽器之后第三方登錄回跳突然拿不到Cookie的原因之一。2.3 Cookie的邊界別把什么都往里塞Cookie雖方便但它絕對(duì)不是用來裝大數(shù)據(jù)的。瀏覽器的Cookie容量很小一般單域名Cookie總量也就4KB左右這是瀏覽器的實(shí)際實(shí)現(xiàn)約束不是RFC強(qiáng)制規(guī)定單個(gè)Cookie大小在幾千字節(jié)以內(nèi)數(shù)量上也有限制。除了體積限制還有個(gè)更要命的問題Cookie會(huì)在每次請(qǐng)求時(shí)自動(dòng)攜帶。如果你把一個(gè)大對(duì)象塞進(jìn)Cookie那么你的每個(gè)請(qǐng)求頭都會(huì)被撐大不僅浪費(fèi)帶寬某些網(wǎng)關(guān)或代理甚至可能因?yàn)檎?qǐng)求頭過大直接給你返回4xx錯(cuò)誤。我見過有人把整份用戶資料JSON序列化之后塞進(jìn)Cookie的結(jié)果接口頻繁報(bào)錯(cuò)做了半天排查才發(fā)現(xiàn)是Cookie體積超標(biāo)。正確的做法是Cookie里只放一個(gè)不透明的標(biāo)識(shí)符比如會(huì)話ID或者Token具體數(shù)據(jù)存在服務(wù)端或者編碼在憑證本身里。2.4 為什么不能只在Cookie里存用戶名有人會(huì)問那我把用戶名直接存進(jìn)Cookie服務(wù)器讀出來不就知道我是誰了嗎何必搞Session和Token這個(gè)方案不是完全不行但有兩個(gè)問題繞不過去。第一你沒法校驗(yàn)這個(gè)Cookie是不是被篡改過的。你存一個(gè)usernameadmin攻擊者直接在瀏覽器里改成usernameroot服務(wù)器毫無察覺地就信了。第二你沒法控制它失效。用戶改密碼、管理員封號(hào)Cookie還在用戶依然能繼續(xù)訪問。真正合理的做法是Cookie里存的是無法被普通人偽造的隨機(jī)憑證或簽名憑證服務(wù)器驗(yàn)證的是這個(gè)憑證本身而不是直接信任憑證明文里的信息。這也是Session和Token這兩個(gè)方案存在的根本意義。3. Session機(jī)制深挖服務(wù)端的“登記冊(cè)”3.1 Session的工作流程與存儲(chǔ)位置Session方案的核心思想是把用戶狀態(tài)放在服務(wù)端客戶端只保留一個(gè)會(huì)話ID。完整流程是用戶提交用戶名密碼服務(wù)器校驗(yàn)通過后創(chuàng)建一個(gè)Session記錄并生成一個(gè)隨機(jī)的Session ID。服務(wù)器通過Set-Cookie把Session ID發(fā)給瀏覽器。瀏覽器后續(xù)請(qǐng)求自動(dòng)攜帶這個(gè)Session ID。服務(wù)器根據(jù)Session ID去Session存儲(chǔ)里查找對(duì)應(yīng)的數(shù)據(jù)比如用戶ID、角色權(quán)限、過期時(shí)間。如果找到且沒過期就認(rèn)為請(qǐng)求已認(rèn)證繼續(xù)處理業(yè)務(wù)。這里Session ID本身通常不帶業(yè)務(wù)含義它就像一把鑰匙上的編號(hào)號(hào)碼本身沒有意義關(guān)鍵是服務(wù)端的“登記冊(cè)”里對(duì)應(yīng)那條記錄。實(shí)際項(xiàng)目里Session數(shù)據(jù)可以存哪從簡(jiǎn)單到復(fù)雜有幾種選擇內(nèi)存存儲(chǔ)直接存在服務(wù)器進(jìn)程內(nèi)存里讀快但麻煩多——服務(wù)一重啟就全沒了而且多實(shí)例部署的時(shí)候沒法共享。外部緩存最常用的是Redis所有后端實(shí)例共用一份Session數(shù)據(jù)服務(wù)重啟不影響多機(jī)部署也能正常工作。數(shù)據(jù)庫可以存關(guān)系型數(shù)據(jù)庫或文檔數(shù)據(jù)庫除非有審計(jì)和離線分析需求否則一般沒必要因?yàn)樾阅軉栴}首選數(shù)據(jù)庫。生產(chǎn)環(huán)境我基本只用Redis方案原因很簡(jiǎn)單Session最需要的就是“快”和“共享”Redis兩個(gè)都能滿足。3.2 Session ID的生成與傳輸細(xì)節(jié)Session ID看起來只是一個(gè)隨機(jī)字符串但它的生成質(zhì)量直接決定安全性。如果生成的ID可以被預(yù)測(cè)比如按序號(hào)遞增攻擊者就可以通過偽造ID去冒充別人。所以Session ID必須使用足夠強(qiáng)的隨機(jī)源生成比如加密安全的隨機(jī)數(shù)生成器讓它不可猜測(cè)、不可預(yù)測(cè)。傳輸上前面已經(jīng)說了是借助Cookie。這里有個(gè)細(xì)節(jié)這個(gè)Cookie的名字不一定要叫sessionId你可以自定義但要注意的是它必須被設(shè)為HttpOnly并且名字別跟業(yè)務(wù)Cookie撞上。有些框架默認(rèn)生成的名字可能會(huì)跟你的業(yè)務(wù)Bean字段重復(fù)導(dǎo)致解析錯(cuò)亂這種問題排查起來特別隱蔽。3.3 Session的過期策略與“記住我”邏輯Session不會(huì)永久有效否則服務(wù)端存儲(chǔ)會(huì)越積越多。常見策略是設(shè)置一個(gè)過期時(shí)間比如30分鐘。到期之后用戶重新訪問就相當(dāng)于未登錄狀態(tài)。這里有個(gè)產(chǎn)品層常見的需求“用戶主動(dòng)關(guān)掉瀏覽器再打開還是要保持登錄。”前面說過會(huì)話級(jí)Cookie會(huì)在瀏覽器關(guān)閉時(shí)失效。要實(shí)現(xiàn)“記住我”的效果在做登錄的時(shí)候就需要手動(dòng)把Cookie的過期時(shí)間一并拉長(zhǎng)——但要注意這不等于讓Session永不過期。你必須同時(shí)考慮服務(wù)端Session的過期時(shí)間應(yīng)該大于或等于Cookie的過期時(shí)間否則Cookie還在服務(wù)端記錄卻已經(jīng)沒了用戶看到的依然是“登錄過期請(qǐng)重新登錄”的提示。還要提一下“滑動(dòng)過期”與“固定過期”的區(qū)別?；瑒?dòng)過期意味著只要用戶一直有操作每次操作就往后續(xù)期固定過期則是不管活動(dòng)與否到期一律踢下線。金融、政務(wù)類系統(tǒng)喜歡固定過期防止有人人走忘記關(guān)電腦普通互聯(lián)網(wǎng)產(chǎn)品大多用滑動(dòng)過期體驗(yàn)更順滑。兩種模式?jīng)]有絕對(duì)的好壞按業(yè)務(wù)安全等級(jí)選就行。3.4 Session方案的集群困境與解法Session有一個(gè)很樸素的問題如果應(yīng)用部署了多臺(tái)服務(wù)器用戶在A服務(wù)器登錄了Session存在A的內(nèi)存里下一次請(qǐng)求被負(fù)載均衡轉(zhuǎn)發(fā)到B服務(wù)器B去存儲(chǔ)里查不到這個(gè)Session用戶就被當(dāng)成未登錄了。解法有三個(gè)方向按成本從低到高排列Session粘滯Sticky Session讓負(fù)載均衡把同一個(gè)用戶的所有請(qǐng)求固定轉(zhuǎn)發(fā)到同一臺(tái)服務(wù)器。配置簡(jiǎn)單但機(jī)器故障或發(fā)布擴(kuò)容時(shí)還是會(huì)出問題。Session共享把Session集中存到Redis之類的獨(dú)立存儲(chǔ)里所有服務(wù)器實(shí)例都從同一處讀寫。這是最常用的生產(chǎn)方案既能橫向擴(kuò)容也能平滑發(fā)布。無狀態(tài)化改造壓根不用Session改用Token方案讓服務(wù)器不需要保存任何會(huì)話狀態(tài)。這個(gè)徹底解決了共享問題但也帶來了Token特有的挑戰(zhàn)下一節(jié)詳聊。4. Token認(rèn)證深度解析把信任寫進(jìn)憑證里4.1 JWT的結(jié)構(gòu)與簽名原理Token這個(gè)詞含義很廣但實(shí)際工作中只要說Token絕大多數(shù)人默認(rèn)指JWTJSON Web Token。JWT由三部分組成Header聲明類型和簽名算法比如{alg:HS256,typ:JWT}。Payload放自定義聲明比如用戶ID、過期時(shí)間、角色等。Signature對(duì)前兩部分做簽名得到的防偽串。三部分各自做Base64編碼然后用點(diǎn)號(hào)拼起來最終長(zhǎng)這樣eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c這里必須強(qiáng)調(diào)一個(gè)原則JWT是簽名不是加密。Payload部分做的是Base64編碼任何拿到Token的人都能直接解碼看到里面的明文內(nèi)容。所以絕不允許往Payload里塞密碼、手機(jī)號(hào)、身份證號(hào)之類的敏感數(shù)據(jù)。簽名的作用是防篡改不是防偷看。簽名過程用HS256算法來舉例的話驗(yàn)證邏輯就是拿同樣的密鑰重新把Header和Payload拼起來算一遍HMAC比對(duì)算出來的簽名和Token自帶的簽名是否一致。只要密鑰不泄露哪怕攻擊者把Payload里的role從user改成admin算出來的簽名也對(duì)不上服務(wù)器直接拒收。4.2 Token方案為什么更適合前后端分離和微服務(wù)Session時(shí)代每個(gè)服務(wù)都需要訪問同一個(gè)Session存儲(chǔ)才能認(rèn)出用戶。走到微服務(wù)架構(gòu)時(shí)問題會(huì)變得非常麻煩每個(gè)服務(wù)都得配置到同一個(gè)Redis的連接某次緩存抖動(dòng)可能影響所有服務(wù)。Token方案則完全繞開了這個(gè)問題。只要服務(wù)端能校驗(yàn)Token簽名它就能信任Token里攜帶的身份信息而不需要去翻存儲(chǔ)。這讓認(rèn)證邏輯變成了一個(gè)純粹的計(jì)算動(dòng)作天然適合API網(wǎng)關(guān)、微服務(wù)、移動(dòng)端App這類多端、多服務(wù)的場(chǎng)景。內(nèi)部服務(wù)之間調(diào)用也可以彼此傳遞同一個(gè)Token各自驗(yàn)簽完事。還有一個(gè)場(chǎng)景是移動(dòng)端。App不是瀏覽器沒有一個(gè)自動(dòng)管理Cookie的容器雖然理論上也可以手動(dòng)管理Cookie但姿勢(shì)極其別扭。Token方案下App拿到Token后存在本地安全存儲(chǔ)里每次請(qǐng)求時(shí)手動(dòng)加到Authorization請(qǐng)求頭即可這才是移動(dòng)端的標(biāo)準(zhǔn)玩法。4.3 Token的過期時(shí)間與Refresh Token設(shè)計(jì)Session可以設(shè)置服務(wù)端過期時(shí)間到期不及時(shí)續(xù)期就失效。Token卻有個(gè)特性服務(wù)端無法主動(dòng)讓它失效。因?yàn)榉?wù)端根本不保存Token的狀態(tài)一個(gè)還沒到期的Token即便用戶已經(jīng)注銷甚至被管理員封禁它在剩余有效期內(nèi)依然可以正常使用。要解決這個(gè)問題通常有兩種策略第一種策略是設(shè)置短生命周期Token。比如讓Token只存活15分鐘。但15分鐘一到用戶就被強(qiáng)制要求重新登錄這體驗(yàn)太差了。于是引入Refresh Token——一個(gè)更長(zhǎng)生命周期的憑證比如7天甚至30天專門用來在Access Token過期之后去換一個(gè)新的Access Token。用戶無感知地續(xù)期服務(wù)端要“踢人”時(shí)只需要讓Refresh Token失效下一次換取新Token時(shí)就能攔住。第二種策略是在服務(wù)端維護(hù)一個(gè)Token黑名單或Token白名單。黑名單存儲(chǔ)“還沒到期但已被吊銷”的Token白名單則把所有有效Token存下來。這兩種做法本質(zhì)上又引入了服務(wù)端狀態(tài)Token“無狀態(tài)”的優(yōu)勢(shì)就打了折扣但某些安全等級(jí)高的業(yè)務(wù)只能這么做屬于典型的“用復(fù)雜度換控制權(quán)”。我在實(shí)際項(xiàng)目里的取舍是普通互聯(lián)網(wǎng)產(chǎn)品Access Token短命Refresh Token長(zhǎng)命就夠了金融、后臺(tái)管理類系統(tǒng)再疊加一個(gè)服務(wù)端白名單多一道保險(xiǎn)。4.4 Token到底放哪里localStorage還是HttpOnly CookieToken方案下還有一個(gè)經(jīng)典爭(zhēng)論Token該存在瀏覽器哪個(gè)位置存在localStorage里JavaScript可以自由讀取每次請(qǐng)求手動(dòng)塞進(jìn)Authorization請(qǐng)求頭。好處是跨域場(chǎng)景比較靈活缺點(diǎn)是只要頁面被注入惡意腳本Token就能被直接偷走而localStorage對(duì)這類攻擊完全沒有防護(hù)。存在HttpOnly Cookie里瀏覽器自動(dòng)攜帶腳本讀不到。這解決了XSS竊取問題卻引來了CSRF問題——因?yàn)镃ookie是自動(dòng)攜帶的攻擊者可以在另一個(gè)站點(diǎn)偽造請(qǐng)求讓你的瀏覽器帶著Cookie發(fā)出危險(xiǎn)操作。好在有SameSite屬性和CSRF Token機(jī)制可以兜底。我在項(xiàng)目里的默認(rèn)推薦是如果前端是純靜態(tài)頁加API服務(wù)且跨域不是特別復(fù)雜的場(chǎng)景優(yōu)先放HttpOnly Cookie因?yàn)樗腦SS風(fēng)險(xiǎn)面更小如果業(yè)務(wù)必須支持完全跨域的API調(diào)用再把Token放到安全存儲(chǔ)里手動(dòng)管理。沒有絕對(duì)安全的方案只有結(jié)合自己業(yè)務(wù)的取舍。5. 三者的橫向?qū)Ρ扰c選型決策說了這么多原理落到選型這一步直接給一張對(duì)比表方便你收藏以后查。對(duì)比維度Cookie直接存身份信息SessionTokenJWT狀態(tài)存儲(chǔ)位置瀏覽器服務(wù)端憑證本身服務(wù)端是否存儲(chǔ)狀態(tài)否是否純無狀態(tài)時(shí)服務(wù)端擴(kuò)容難度無需處理需要共享存儲(chǔ)天然易擴(kuò)容身份信息篡改難度容易明文不容易依賴服務(wù)端不容易依賴簽名主動(dòng)失效能力強(qiáng)刪Cookie即可強(qiáng)刪Session即可弱到期前無法主動(dòng)失效跨域支持差受同源策略限制差依賴Cookie好可放請(qǐng)求頭移動(dòng)端適配麻煩麻煩標(biāo)準(zhǔn)做法典型場(chǎng)景簡(jiǎn)單個(gè)人偏好記錄傳統(tǒng)服務(wù)端渲染應(yīng)用前后端分離、微服務(wù)、App選型的時(shí)候我一般按這個(gè)思路來快速判斷做傳統(tǒng)服務(wù)端渲染的Web系統(tǒng)比如Java Thymeleaf / PHP / 服務(wù)端模板直接用Cookie Session模式成本最低、框架支持最好、安全模型也成熟。做前后端分離的單頁應(yīng)用如果業(yè)務(wù)只在自家域名內(nèi)跑可以用Session方案也可以把Token放在HttpOnly Cookie里如果接口要給多個(gè)域名共用直接上Token方案配合Refresh Token。做純移動(dòng)端App或小程序直接用Token方案這是移動(dòng)端的事實(shí)標(biāo)準(zhǔn)。做公共服務(wù)平臺(tái)或微服務(wù)架構(gòu)TokenJWT配合網(wǎng)關(guān)統(tǒng)一鑒權(quán)幾乎是唯一合理的選擇。記住一個(gè)原則沒有絕對(duì)先進(jìn)的方案只有當(dāng)前場(chǎng)景下是否合適。好幾年前有人天天鼓吹“Token已全面取代Session”我在實(shí)際項(xiàng)目里看到不少傳統(tǒng)系統(tǒng)里的Session依然跑得很健壯反而是強(qiáng)行上Token后因?yàn)槭C(jī)制沒做完善用戶被無故踢下線體驗(yàn)還不如原來。6. 實(shí)戰(zhàn)排查這幾個(gè)常見坑你遲早會(huì)遇到6.1 登錄成功了但刷新頁面就失效遇到這種問題先按順序排查三個(gè)點(diǎn)第一服務(wù)端種下的Cookie有沒有設(shè)置過期時(shí)間。沒有Expires也沒有Max-Age的話這個(gè)Cookie就是會(huì)話級(jí)Cookie瀏覽器一關(guān)就沒了頁面刷新可能沒事但下次新開Tab就會(huì)失效。第二Cookie過期時(shí)間與Session過期時(shí)間是否匹配。常見做法是Cookie設(shè)了30天但Session存儲(chǔ)只存活30分鐘時(shí)間一到服務(wù)端記錄就沒了Cookie還在又有什么意義我建議Cookie死活時(shí)間跟Session存儲(chǔ)的過期時(shí)間對(duì)齊要么一起長(zhǎng)命要么一起短命。第三Session存儲(chǔ)是否因?yàn)橹貑⒍鴣G失。如果你用的是內(nèi)存Session存儲(chǔ)每次后端服務(wù)重新部署后所有登錄用戶都會(huì)被清掉。生產(chǎn)環(huán)境不能這么玩至少得換Redis。6.2 跨域請(qǐng)求怎么都帶不上Cookie這是前后端分離項(xiàng)目里最常見的問題。瀏覽器跨域請(qǐng)求不會(huì)自動(dòng)帶上目標(biāo)域名的Cookie前端和后端需要同時(shí)做三件事才能打通前端請(qǐng)求要開啟withCredentials在fetch里對(duì)應(yīng)credentials: include后端的CORS響應(yīng)頭必須明確指定允許的Origin不能用*并且設(shè)置Access-Control-Allow-Credentials: true后端種Cookie時(shí)SameSite屬性不能為Strict否則部分跨站場(chǎng)景下根本不會(huì)發(fā)送。以上三個(gè)條件缺一個(gè)跨域登錄就會(huì)失敗而且瀏覽器報(bào)錯(cuò)往往只是輕飄飄一句“CORS error”讓人不知道到底是哪里掛了。排查時(shí)直接打開Network面板看請(qǐng)求頭里有沒有Cookie以及響應(yīng)頭里的Set-Cookie有沒有被瀏覽器攔截能幫你快速定位問題在哪一端。6.3 Token過期了用戶還在頁面上提交時(shí)才告訴你重新登錄這個(gè)坑幾乎只出現(xiàn)在沒做自動(dòng)續(xù)期的Token項(xiàng)目里。Access Token存活期太短用戶停留在頁面上瀏覽太久Token悄悄過期了用戶毫無感知一提交表單直接被彈回登錄頁寫了半天的內(nèi)容全沒了。這是極其勸退的產(chǎn)品體驗(yàn)。解決方案是分兩條腿走第一必要的地方加心跳檢測(cè)——定時(shí)用一個(gè)輕量接口驗(yàn)證登錄態(tài)快過期時(shí)主動(dòng)用Refresh Token換新Token第二在發(fā)起業(yè)務(wù)請(qǐng)求遇到“認(rèn)證失敗”時(shí)先嘗試用Refresh Token靜默續(xù)期一次續(xù)期成功就重放剛才的請(qǐng)求。這樣用戶全程無感知體驗(yàn)自然就順了。還要提醒一句Refresh Token必須要比Access Token更小心保存。它權(quán)力更大、壽命更長(zhǎng)一旦泄露等于“永久的鑰匙”。有條件的話Refresh Token應(yīng)該做設(shè)備綁定防止別人拿你的Refresh Token去別的設(shè)備換Token。6.4 明明設(shè)置了HttpOnly跨站腳本還是偷到了數(shù)據(jù)HttpOnly只是保護(hù)Cookie不被JS讀取但它管不住攻擊面更大的API接口。一個(gè)典型的攻擊鏈路是攻擊者在頁面里注入腳本腳本不會(huì)去讀document.cookie而是直接向服務(wù)端發(fā)請(qǐng)求拉數(shù)據(jù)——因?yàn)橹灰獮g覽器帶了有效的認(rèn)證Cookie這個(gè)請(qǐng)求在服務(wù)端看來完全合法。所以HttpOnly不等于免疫XSS。該做的防御還是要做所有輸入要校驗(yàn)、輸出要轉(zhuǎn)義、內(nèi)容安全策略CSP要配好、持久型XSS要重點(diǎn)防。認(rèn)證憑證這塊再安全輸入口被打穿一樣防不住。6.5 Cookie體積過大導(dǎo)致請(qǐng)求異常我之前排查過一個(gè)詭異的問題接口在測(cè)試環(huán)境一切正常生產(chǎn)環(huán)境偶爾報(bào)錯(cuò)而且報(bào)錯(cuò)完全沒有規(guī)律。后來看網(wǎng)絡(luò)日志才發(fā)現(xiàn)一個(gè)請(qǐng)求的Header體積已經(jīng)超過2KB而生產(chǎn)環(huán)境的網(wǎng)關(guān)對(duì)Header總大小有限制超過就拒絕處理。原因就是有人把用戶菜單數(shù)據(jù)序列化塞進(jìn)了Cookie每幀請(qǐng)求都帶著這一大包走自然容易觸頂。這種問題排查起來非常費(fèi)勁因?yàn)槟阕约簽g覽器里未必復(fù)現(xiàn)等到高流量機(jī)器上日志刷屏才發(fā)現(xiàn)是Header超限。好的實(shí)踐是Cookie里只放ID數(shù)據(jù)走接口拉或者只放簽名過的Token業(yè)務(wù)數(shù)據(jù)一律放服務(wù)端。請(qǐng)求頭越瘦出問題的概率越低。6.6 同一個(gè)瀏覽器前后登錄的賬號(hào)狀態(tài)串了多賬號(hào)切換在同一瀏覽器下是隱藏高頻事故點(diǎn)。常見場(chǎng)景是用戶先登錄A賬號(hào)退出后又登錄了B賬號(hào)結(jié)果頁面顯示的卻還是A賬號(hào)的某些信息。原因往往在于退出登錄時(shí)只刪了業(yè)務(wù)側(cè)的登錄態(tài)沒刪干凈或者Token的Key使用了固定的字符串不同用戶之間產(chǎn)生了緩存覆蓋。解決這個(gè)問題沒有太多花活就是規(guī)范好狀態(tài)生命周期登錄時(shí)統(tǒng)一寫入退出時(shí)統(tǒng)一清除多個(gè)頁面Tab之間盡量用同一套會(huì)話狀態(tài)管理邏輯不要在業(yè)務(wù)里到處手動(dòng)改認(rèn)證數(shù)據(jù)。你偷懶跳過哪一步線上就會(huì)以詭異的方式回報(bào)你。用經(jīng)驗(yàn)說話幾個(gè)掏心窩的建議嘮了大半天理論、實(shí)操、坑都聊了最后分享幾個(gè)我這些年積攢下來的切身體會(huì)。第一個(gè)建議是別一聽“Token更新”就無腦遷移。技術(shù)上哪種方案更“先進(jìn)”不重要重要的是你的業(yè)務(wù)場(chǎng)景更適合哪種。老系統(tǒng)用Session好好的你沒有充分理由就別折騰。第二個(gè)是認(rèn)證這塊一定要灰度上線。不管是Session存儲(chǔ)從內(nèi)存換成Redis還是從Session方案切到Token方案都別一把梭。先挑一個(gè)低風(fēng)險(xiǎn)模塊做小流量驗(yàn)證觀察認(rèn)證錯(cuò)誤率、用戶反饋、服務(wù)端異常日志再逐步擴(kuò)大范圍。我見過太多人一把切過去第二天早晨線上單子滿天飛。第三個(gè)是寫登錄認(rèn)證相關(guān)的代碼時(shí)把日志打到位。認(rèn)證失敗和業(yè)務(wù)失敗不一樣它需要看到“是誰在什么時(shí)間從哪里請(qǐng)求了什么接口、為什么被拒”。沒有充分日志的時(shí)候排查認(rèn)證問題就像閉著眼睛找東西效率極其低下。說回標(biāo)題那三個(gè)詞——Cookie、Session、Token它們沒有哪個(gè)該被踩到泥里也無所謂誰“更好”。它們回答的是同一個(gè)問題只是答案的思路不同。你在任何項(xiàng)目里只要想清楚“狀態(tài)放哪”“怎么驗(yàn)證”這兩件事再根據(jù)實(shí)際場(chǎng)景權(quán)衡一下安全、體驗(yàn)、復(fù)雜度選型就不會(huì)出錯(cuò)。這套思路我用到現(xiàn)在還沒遇到過它們擺脫不掉的場(chǎng)景。