什么是認(rèn)證（Authentication）

通俗地講就是驗(yàn)證當(dāng)前用戶的身份蔫敲，證明“你是你自己”（比如：你每天上下班打卡，都需要通過(guò)指紋打卡，當(dāng)你的指紋和系統(tǒng)里錄入的指紋相匹配時(shí)宫盔，就打卡成功）

互聯(lián)網(wǎng)中的認(rèn)證：

用戶名密碼登錄

郵箱發(fā)送登錄鏈接

手機(jī)號(hào)接收驗(yàn)證碼

只要你能收到郵箱/驗(yàn)證碼盏浙，就默認(rèn)你是賬號(hào)的主人

什么是授權(quán)（Authorization）

用戶授予第三方應(yīng)用訪問(wèn)該用戶某些資源的權(quán)限

你在安裝手機(jī)應(yīng)用的時(shí)候眉睹，APP 會(huì)詢問(wèn)是否允許授予權(quán)限（訪問(wèn)相冊(cè)荔茬、地理位置等權(quán)限）

你在訪問(wèn)微信小程序時(shí)，當(dāng)?shù)卿洉r(shí)竹海，小程序會(huì)詢問(wèn)是否允許授予權(quán)限（獲取昵稱慕蔚、頭像、地區(qū)斋配、性別等個(gè)人信息）

實(shí)現(xiàn)授權(quán)的方式有：cookie孔飒、session、token艰争、OAuth

什么是憑證（Credentials）

實(shí)現(xiàn)認(rèn)證和授權(quán)的前提是需要一種媒介（證書） 來(lái)標(biāo)記訪問(wèn)者的身份

在戰(zhàn)國(guó)時(shí)期坏瞄，商鞅變法，發(fā)明了照身帖甩卓。照身帖由官府發(fā)放鸠匀，是一塊打磨光滑細(xì)密的竹板，上面刻有持有人的頭像和籍貫信息逾柿。國(guó)人必須持有狮崩，如若沒有就被認(rèn)為是黑戶，或者間諜之類的鹿寻。

在現(xiàn)實(shí)生活中睦柴，每個(gè)人都會(huì)有一張專屬的居民身份證，是用于證明持有人身份的一種法定證件毡熏。通過(guò)身份證坦敌，我們可以辦理手機(jī)卡/銀行卡/個(gè)人貸款/交通出行等等，這就是認(rèn)證的憑證痢法。

在互聯(lián)網(wǎng)應(yīng)用中狱窘，一般網(wǎng)站（如掘金）會(huì)有兩種模式，游客模式和登錄模式财搁。游客模式下蘸炸，可以正常瀏覽網(wǎng)站上面的文章，一旦想要點(diǎn)贊/收藏/分享文章尖奔，就需要登錄或者注冊(cè)賬號(hào)搭儒。當(dāng)用戶登錄成功后，服務(wù)器會(huì)給該用戶使用的瀏覽器頒發(fā)一個(gè)令牌（token）提茁，這個(gè)令牌用來(lái)表明你的身份淹禾，每次瀏覽器發(fā)送請(qǐng)求時(shí)會(huì)帶上這個(gè)令牌，就可以使用游客模式下無(wú)法使用的功能茴扁。

什么是 Cookie

HTTP 是無(wú)狀態(tài)的協(xié)議（對(duì)于事務(wù)處理沒有記憶能力铃岔，每次客戶端和服務(wù)端會(huì)話完成時(shí)，服務(wù)端不會(huì)保存任何會(huì)話信息）：每個(gè)請(qǐng)求都是完全獨(dú)立的峭火，服務(wù)端無(wú)法確認(rèn)當(dāng)前訪問(wèn)者的身份信息毁习，無(wú)法分辨上一次的請(qǐng)求發(fā)送者和這一次的發(fā)送者是不是同一個(gè)人智嚷。所以服務(wù)器與瀏覽器為了進(jìn)行會(huì)話跟蹤（知道是誰(shuí)在訪問(wèn)我），就必須主動(dòng)的去維護(hù)一個(gè)狀態(tài)纺且，這個(gè)狀態(tài)用于告知服務(wù)端前后兩個(gè)請(qǐng)求是否來(lái)自同一瀏覽器纤勒。而這個(gè)狀態(tài)需要通過(guò) cookie 或者 session 去實(shí)現(xiàn)。

cookie 存儲(chǔ)在客戶端：cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)隆檀，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)被攜帶并發(fā)送到服務(wù)器上摇天。

cookie 是不可跨域的：每個(gè) cookie 都會(huì)綁定單一的域名，無(wú)法在別的域名下獲取使用恐仑，一級(jí)域名和二級(jí)域名之間是允許共享使用的（靠的是 domain）泉坐。

Cookie 和 Session 區(qū)別

1.cookie 是一種發(fā)送到客戶瀏覽器的文本串句柄，并保存在客戶機(jī)硬盤上裳仆，可以用來(lái)在某個(gè)WEB站點(diǎn)會(huì)話間持久的保持?jǐn)?shù)據(jù)腕让。

2.session其實(shí)指的就是訪問(wèn)者從到達(dá)某個(gè)特定主頁(yè)到離開為止的那段時(shí)間。 Session其實(shí)是利用Cookie進(jìn)行信息處理的歧斟，當(dāng)用戶首先進(jìn)行了請(qǐng)求后纯丸，服務(wù)端就在用戶瀏覽器上創(chuàng)建了一個(gè)Cookie，當(dāng)這個(gè)Session結(jié)束時(shí)静袖，其實(shí)就是意味著這個(gè)Cookie就過(guò)期了觉鼻。

注：為這個(gè)用戶創(chuàng)建的Cookie的名稱是aspsessionid。這個(gè)Cookie的唯一目的就是為每一個(gè)用戶提供不同的身份認(rèn)證队橙。

3.cookie和session的共同之處在于：cookie和session都是用來(lái)跟蹤瀏覽器用戶身份的會(huì)話方式坠陈。

4.cookie 和session的區(qū)別是：cookie數(shù)據(jù)保存在客戶端，session數(shù)據(jù)保存在服務(wù)器端捐康。

兩個(gè)都可以用來(lái)存私密的東西仇矾，同樣也都有有效期的說(shuō)法,區(qū)別在于session是放在服務(wù)器上的，過(guò)期與否取決于服務(wù)期的設(shè)定解总，cookie是存在客戶端的贮匕，過(guò)去與否可以在cookie生成的時(shí)候設(shè)置進(jìn)去。

(1)cookie數(shù)據(jù)存放在客戶的瀏覽器上花枫，session數(shù)據(jù)放在服務(wù)器上

(2)cookie不是很安全刻盐，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙,如果主要考慮到安全應(yīng)當(dāng)使用session

(3)session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問(wèn)增多乌昔，會(huì)比較占用你服務(wù)器的性能隙疚，如果主要考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE

(4)單個(gè)cookie在客戶端的限制是3K磕道，就是說(shuō)一個(gè)站點(diǎn)在客戶端存放的COOKIE不能3K。

(5)所以：將登陸信息等重要信息存放為SESSION;其他信息如果需要保留行冰，可以放在COOKIE中

?Cookie技術(shù)的4個(gè)組件：

(1) 在HTTP響應(yīng)報(bào)文中的一個(gè)cookie首部行溺蕉。

(2) 在HTTP請(qǐng)求報(bào)文中的一個(gè)cookie首部行伶丐。

(3) 在用戶端系統(tǒng)中保留一個(gè)cookie文件，由用戶的瀏覽器進(jìn)行管理疯特。

(4) 位于Web站點(diǎn)的一個(gè)后端數(shù)據(jù)庫(kù)哗魂。

Cookie技術(shù)通過(guò)在請(qǐng)求和響應(yīng)報(bào)文中寫入Cookie信息來(lái)控制客戶端的狀態(tài)。其具體工作流程如下所示

(1) 當(dāng)用戶訪問(wèn)某個(gè)使用Cookie的網(wǎng)站時(shí)漓雅，該網(wǎng)站的服務(wù)器就為用戶產(chǎn)生一個(gè)唯一的識(shí)別碼录别，并以此作為索引在服務(wù)器的后端服務(wù)器數(shù)據(jù)庫(kù)中產(chǎn)生一個(gè)表項(xiàng)。

(2) 服務(wù)器在給用戶的HTTP響應(yīng)報(bào)文中添加一個(gè)叫做Set-Cookie的首部行邻吞。如Set-Cookie : 1234

(3) 當(dāng)用戶收到這個(gè)響應(yīng)時(shí)组题，其瀏覽器就在它管理的特定的Cookie文件中添加一行，其中包括這個(gè)服務(wù)器主機(jī)名和Set-Cookie后面的給出的識(shí)別碼抱冷。當(dāng)用戶繼續(xù)瀏覽這個(gè)網(wǎng)站時(shí)崔列，每發(fā)送一個(gè)HTTP請(qǐng)求報(bào)文，其瀏覽器就會(huì)從Cookie文件中取出這個(gè)網(wǎng)站的識(shí)別碼旺遮，并放到HTTP請(qǐng)求報(bào)文的Cookie首部行中赵讯，即Coolkie : 1234。

(4) 如果過(guò)段時(shí)間用戶再次訪問(wèn)該網(wǎng)站時(shí)耿眉，那么瀏覽器會(huì)在其請(qǐng)求報(bào)文中繼續(xù)使用首部行Cookie:1234边翼，如果用戶在該網(wǎng)站上保存了姓名、電子郵件等信息鸣剪，服務(wù)器可以使用Cookie來(lái)驗(yàn)證該用戶讯私，因此以后用戶在網(wǎng)站購(gòu)物時(shí)就不必在重新輸入姓名等信息了，對(duì)用戶顯然是很方便的西傀。

條件GET方法

??盡管緩存能夠減少響應(yīng)時(shí)間斤寇，但是也引入了一個(gè)新的問(wèn)題——緩存的有效性問(wèn)題。

當(dāng)遇上服務(wù)器上的資源更新時(shí)拥褂，如果還是使用原來(lái)的緩存娘锁，那么就會(huì)出現(xiàn)緩存不一致的問(wèn)題。

HTTP協(xié)議有一種機(jī)制饺鹃，允許緩存證實(shí)它的對(duì)象是最新的莫秆。這種機(jī)制就是條件GET方法。

??如果請(qǐng)求報(bào)文使用的是GET方法悔详，并且請(qǐng)求報(bào)文中含一個(gè)“If-Modified-Since”首部行镊屎。那么，這個(gè)HTTP請(qǐng)求就是一個(gè)條件GET請(qǐng)求報(bào)文茄螃。下面用一個(gè)例子說(shuō)明一下條件GET方法缝驳。

??首先，一個(gè)代理服務(wù)器代表一個(gè)請(qǐng)求瀏覽器，向某個(gè)Web服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文：

??其次用狱，該Web服務(wù)器向代理服務(wù)器發(fā)送具有被請(qǐng)求對(duì)象的響應(yīng)報(bào)文：

??代理服務(wù)器將該對(duì)象保存在本地磁盤中运怖。注意，響應(yīng)報(bào)文中的紅色部分夏伊，表示該對(duì)象的最后修改日期摇展。

??一段時(shí)間后，另一個(gè)用戶經(jīng)過(guò)緩存請(qǐng)求同一個(gè)對(duì)象溺忧，該對(duì)象仍在代理服務(wù)器中咏连，由于過(guò)了一段時(shí)間了，Web服務(wù)器上的該對(duì)象可能已經(jīng)被修改過(guò)了鲁森，所以代理服務(wù)器通過(guò)發(fā)送一個(gè)條件GET執(zhí)行最新檢查祟滴。具體來(lái)說(shuō)，該代理服務(wù)器發(fā)送：

??這里刀森，請(qǐng)求報(bào)文中的If-Modified首部行的值和之前響應(yīng)報(bào)文中Last-Modified首部行的值一樣踱启。這個(gè)條件GET報(bào)文告訴服務(wù)器，如果在指定日期后該對(duì)象被修改過(guò)研底，才發(fā)送該對(duì)象埠偿。通俗來(lái)說(shuō)，就是代理服務(wù)器告訴服務(wù)器如果在2011年9月7日 09:23:24之后對(duì)該對(duì)象有修改過(guò)榜晦，那就把修改過(guò)的對(duì)象發(fā)送給我冠蒋。

??假設(shè)該對(duì)象沒有被修改過(guò)，那么Web服務(wù)器向代理服務(wù)器發(fā)送一個(gè)響應(yīng)報(bào)文：

??304 響應(yīng)碼表示請(qǐng)求的對(duì)象沒有被修改乾胶。所以抖剿，響應(yīng)體的內(nèi)容是空沒有包含對(duì)象，由于對(duì)象沒有被修改识窿，即代理服務(wù)器中的對(duì)象和Web服務(wù)器中的該對(duì)象是一致的斩郎，所有Web服務(wù)器沒必要再傳送一次該對(duì)象，包含對(duì)象只會(huì)浪費(fèi)帶寬喻频，并增加用戶的響應(yīng)時(shí)間缩宜。

什么是 Session

session 是另一種記錄服務(wù)器和客戶端會(huì)話狀態(tài)的機(jī)制

session 是基于 cookie 實(shí)現(xiàn)的，session 存儲(chǔ)在服務(wù)器端甥温，sessionId 會(huì)被存儲(chǔ)到客戶端的cookie 中

session 認(rèn)證流程：

用戶第一次請(qǐng)求服務(wù)器的時(shí)候锻煌，服務(wù)器根據(jù)用戶提交的相關(guān)信息，創(chuàng)建對(duì)應(yīng)的 Session

請(qǐng)求返回時(shí)將此 Session 的唯一標(biāo)識(shí)信息 SessionID 返回給瀏覽器

瀏覽器接收到服務(wù)器返回的 SessionID 信息后姻蚓，會(huì)將此信息存入到 Cookie 中宋梧，同時(shí) Cookie 記錄此 SessionID 屬于哪個(gè)域名

當(dāng)用戶第二次訪問(wèn)服務(wù)器的時(shí)候，請(qǐng)求會(huì)自動(dòng)判斷此域名下是否存在 Cookie 信息狰挡，如果存在自動(dòng)將 Cookie 信息也發(fā)送給服務(wù)端捂龄，服務(wù)端會(huì)從 Cookie 中獲取 SessionID释涛，再根據(jù) SessionID 查找對(duì)應(yīng)的 Session 信息，如果沒有找到說(shuō)明用戶沒有登錄或者登錄失效跺讯，如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作枢贿。

根據(jù)以上流程可知殉农，SessionID 是連接 Cookie 和 Session 的一道橋梁刀脏，大部分系統(tǒng)也是根據(jù)此原理來(lái)驗(yàn)證用戶登錄狀態(tài)。

Session 建立過(guò)程：

首先超凳，客戶端會(huì)發(fā)送一個(gè)http請(qǐng)求到服務(wù)器端愈污。

服務(wù)器端接受客戶端請(qǐng)求后，建立一個(gè)session轮傍，并發(fā)送一個(gè)http響應(yīng)到客戶端暂雹，這個(gè)響應(yīng)頭，其中就包含Set-Cookie頭部创夜。該頭部包含了sessionId杭跪。Set-Cookie格式如下，具體請(qǐng)看Cookie詳解

Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

在客戶端發(fā)起的第二次請(qǐng)求驰吓，假如服務(wù)器給了set-Cookie涧尿，瀏覽器會(huì)自動(dòng)在請(qǐng)求頭中添加cookie

服務(wù)器接收請(qǐng)求，分解cookie檬贰，驗(yàn)證信息姑廉，核對(duì)成功后返回response給客戶端

什么是 Token（令牌）

Acesss Token

訪問(wèn)資源接口（API）時(shí)所需要的資源憑證

簡(jiǎn)單 token 的組成：uid(用戶唯一的身份標(biāo)識(shí))、time(當(dāng)前時(shí)間的時(shí)間戳)翁涤、sign（簽名桥言，token 的前幾位以哈希算法壓縮成的一定長(zhǎng)度的十六進(jìn)制字符串）

token 的身份驗(yàn)證流程：

1.客戶端使用用戶名跟密碼請(qǐng)求登錄

2.服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼

3.驗(yàn)證成功后葵礼，服務(wù)端會(huì)簽發(fā)一個(gè) token 并把這個(gè) token 發(fā)送給客戶端

4.客戶端收到 token 以后号阿，會(huì)把它存儲(chǔ)起來(lái)，比如放在 cookie 里或者 localStorage 里

5.客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的 token

6.服務(wù)端收到請(qǐng)求鸳粉，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的 token 扔涧，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)

7.每一次請(qǐng)求都需要攜帶 token赁严，需要把 token 放到 HTTP 的 Header 里

基于 token 的用戶認(rèn)證是一種服務(wù)端無(wú)狀態(tài)的認(rèn)證方式扰柠，服務(wù)端不用存放 token 數(shù)據(jù)。用解析 token 的計(jì)算時(shí)間換取 session 的存儲(chǔ)空間疼约，從而減輕服務(wù)器的壓力卤档，減少頻繁的查詢數(shù)據(jù)庫(kù)

token 完全由應(yīng)用管理，所以它可以避開同源策略程剥，token 也稱作令牌劝枣，由uid+time+sign[+固定參數(shù)]

token 的認(rèn)證方式類似于臨時(shí)的證書簽名, 并且是一種服務(wù)端無(wú)狀態(tài)的認(rèn)證方式, 非常適合于 REST API 的場(chǎng)景. 所謂無(wú)狀態(tài)就是服務(wù)端并不會(huì)保存身份認(rèn)證相關(guān)的數(shù)據(jù)汤踏。

token可以抵抗csrf，cookie+session不行

假如用戶正在登陸銀行網(wǎng)頁(yè)舔腾，同時(shí)登陸了攻擊者的網(wǎng)頁(yè)溪胶，并且銀行網(wǎng)頁(yè)未對(duì)csrf攻擊進(jìn)行防護(hù)。攻擊者就可以在網(wǎng)頁(yè)放一個(gè)表單稳诚，該表單提交src為http://www.bank.com/api/transfer哗脖，body為count=1000&to=Tom。倘若是session+cookie扳还，用戶打開網(wǎng)頁(yè)的時(shí)候就已經(jīng)轉(zhuǎn)給Tom1000元了.因?yàn)閒orm 發(fā)起的 POST 請(qǐng)求并不受到瀏覽器同源策略的限制才避，因此可以任意地使用其他域的 Cookie 向其他域發(fā)送 POST 請(qǐng)求，形成 CSRF 攻擊氨距。在post請(qǐng)求的瞬間霎桅，cookie會(huì)被瀏覽器自動(dòng)添加到請(qǐng)求頭中讹俊。但token不同，token是開發(fā)者為了防范csrf而特別設(shè)計(jì)的令牌，瀏覽器不會(huì)自動(dòng)添加到headers里揪漩，攻擊者也無(wú)法訪問(wèn)用戶的token燃观，所以提交的表單無(wú)法通過(guò)服務(wù)器過(guò)濾叶组，也就無(wú)法形成攻擊

session存儲(chǔ)于服務(wù)器阶祭，可以理解為一個(gè)狀態(tài)列表，擁有一個(gè)唯一識(shí)別符號(hào)sessionId沙廉，通常存放于cookie中拘荡。服務(wù)器收到cookie后解析出sessionId，再去session列表中查找撬陵，才能找到相應(yīng)session珊皿。依賴cookie

cookie類似一個(gè)令牌，裝有sessionId巨税，存儲(chǔ)在客戶端蟋定，瀏覽器通常會(huì)自動(dòng)添加。

token也類似一個(gè)令牌草添，無(wú)狀態(tài)驶兜，用戶信息都被加密到token中，服務(wù)器收到token后解密就可知道是哪個(gè)用戶远寸。需要開發(fā)者手動(dòng)添加抄淑。

Token 和 Session 的區(qū)別

Session 是一種記錄服務(wù)器和客戶端會(huì)話狀態(tài)的機(jī)制，使服務(wù)端有狀態(tài)化驰后，可以記錄會(huì)話信息肆资。而 Token 是令牌，訪問(wèn)資源接口（API）時(shí)所需要的資源憑證灶芝。Token 使服務(wù)端無(wú)狀態(tài)化郑原，不會(huì)存儲(chǔ)會(huì)話信息唉韭。

Session 和 Token 并不矛盾，作為身份認(rèn)證 Token 安全性比 Session 好犯犁，因?yàn)槊恳粋€(gè)請(qǐng)求都有簽名還能防止監(jiān)聽以及重放攻擊属愤，而 Session 就必須依賴鏈路層來(lái)保障通訊安全了。如果你需要實(shí)現(xiàn)有狀態(tài)的會(huì)話酸役，仍然可以增加 Session 來(lái)在服務(wù)器端保存一些狀態(tài)住诸。

所謂 Session 認(rèn)證只是簡(jiǎn)單的把 User 信息存儲(chǔ)到 Session 里，因?yàn)?SessionID 的不可預(yù)測(cè)性簇捍，暫且認(rèn)為是安全的只壳。而 Token 俏拱，如果指的是 OAuth Token 或類似的機(jī)制的話暑塑，提供的是 認(rèn)證 和 授權(quán) ，認(rèn)證是針對(duì)用戶锅必，授權(quán)是針對(duì) App 事格。其目的是讓某 App 有權(quán)利訪問(wèn)某用戶的信息。這里的 Token 是唯一的搞隐。不可以轉(zhuǎn)移到其它 App上驹愚，也不可以轉(zhuǎn)到其它用戶上。Session 只提供一種簡(jiǎn)單的認(rèn)證劣纲，即只要有此 SessionID 逢捺，即認(rèn)為有此 User 的全部權(quán)利。是需要嚴(yán)格保密的癞季，這個(gè)數(shù)據(jù)應(yīng)該只保存在站方劫瞳，不應(yīng)該共享給其它網(wǎng)站或者第三方 App。所以簡(jiǎn)單來(lái)說(shuō)：如果你的用戶數(shù)據(jù)可能需要和第三方共享绷柒，或者允許第三方調(diào)用 API 接口志于，用 Token 。如果永遠(yuǎn)只是自己的網(wǎng)站废睦，自己的 App伺绽，用什么就無(wú)所謂了。

session的工作原理

當(dāng)客戶端需要和服務(wù)端進(jìn)行會(huì)話的時(shí)候嗜湃，請(qǐng)求發(fā)送到服務(wù)端奈应。服務(wù)端會(huì)先檢查這個(gè)請(qǐng)求里是否包含了一個(gè)sessionId。如果已經(jīng)包含购披，服務(wù)端可以根據(jù)此sessionId檢索出session來(lái)使用杖挣。如果檢索不出來(lái)(session已經(jīng)失效被刪除了)服務(wù)端會(huì)針對(duì)這個(gè)sessionId新建一個(gè)session。如果客戶端請(qǐng)求不包括sessionId這個(gè)值今瀑，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的sessionid程梦。寫入cookie.

Token 和 Session 的區(qū)別

Session 是一種記錄服務(wù)器和客戶端會(huì)話狀態(tài)的機(jī)制点把，使服務(wù)端有狀態(tài)化，可以記錄會(huì)話信息屿附。而 Token 是令牌郎逃，訪問(wèn)資源接口（API）時(shí)所需要的資源憑證。Token 使服務(wù)端無(wú)狀態(tài)化挺份，不會(huì)存儲(chǔ)會(huì)話信息褒翰。

Session 和 Token 并不矛盾，作為身份認(rèn)證 Token 安全性比 Session 好匀泊，因?yàn)槊恳粋€(gè)請(qǐng)求都有簽名還能防止監(jiān)聽以及重放攻擊优训，而 Session 就必須依賴鏈路層來(lái)保障通訊安全了。如果你需要實(shí)現(xiàn)有狀態(tài)的會(huì)話各聘，仍然可以增加 Session 來(lái)在服務(wù)器端保存一些狀態(tài)揣非。

所謂 Session 認(rèn)證只是簡(jiǎn)單的把 User 信息存儲(chǔ)到 Session 里，因?yàn)?SessionID 的不可預(yù)測(cè)性躲因，暫且認(rèn)為是安全的早敬。而 Token ，如果指的是 OAuth Token 或類似的機(jī)制的話大脉，提供的是 認(rèn)證 和 授權(quán) 搞监，認(rèn)證是針對(duì)用戶，授權(quán)是針對(duì) App 镰矿。其目的是讓某 App 有權(quán)利訪問(wèn)某用戶的信息琐驴。這里的 Token 是唯一的。不可以轉(zhuǎn)移到其它 App上秤标，也不可以轉(zhuǎn)到其它用戶上绝淡。Session 只提供一種簡(jiǎn)單的認(rèn)證，即只要有此 SessionID 抛杨，即認(rèn)為有此 User 的全部權(quán)利够委。是需要嚴(yán)格保密的，這個(gè)數(shù)據(jù)應(yīng)該只保存在站方怖现，不應(yīng)該共享給其它網(wǎng)站或者第三方 App茁帽。所以簡(jiǎn)單來(lái)說(shuō)：如果你的用戶數(shù)據(jù)可能需要和第三方共享，或者允許第三方調(diào)用 API 接口屈嗤，用 Token 潘拨。如果永遠(yuǎn)只是自己的網(wǎng)站，自己的 App饶号，用什么就無(wú)所謂了铁追。

什么是 JWT

JSON Web Token（簡(jiǎn)稱 JWT）是目前最流行的跨域認(rèn)證解決方案。

JWT 認(rèn)證流程：

用戶輸入用戶名/密碼登錄茫船，服務(wù)端認(rèn)證成功后琅束，會(huì)返回給客戶端一個(gè) JWT

客戶端將 token 保存到本地（通常使用 localstorage扭屁，也可以使用 cookie）

當(dāng)用戶希望訪問(wèn)一個(gè)受保護(hù)的路由或者資源的時(shí)候，需要請(qǐng)求頭的 Authorization 字段中使用Bearer 模式添加 JWT涩禀，其內(nèi)容看起來(lái)是下面這樣

Token 和 JWT 的區(qū)別

相同：

都是訪問(wèn)資源的令牌, 都可以記錄用戶的信息, 都是使服務(wù)端無(wú)狀態(tài)化, 都是只有驗(yàn)證成功后料滥，客戶端才能訪問(wèn)服務(wù)端上受保護(hù)的資源

區(qū)別：

Token：服務(wù)端驗(yàn)證客戶端發(fā)送過(guò)來(lái)的 Token 時(shí)，還需要查詢數(shù)據(jù)庫(kù)獲取用戶信息艾船，然后驗(yàn)證 Token 是否有效葵腹。

JWT：將 Token 和 Payload 加密后存儲(chǔ)于客戶端，服務(wù)端只需要使用密鑰解密進(jìn)行校驗(yàn)（校驗(yàn)也是 JWT 自己實(shí)現(xiàn)的）即可屿岂，不需要查詢或者減少查詢數(shù)據(jù)庫(kù)践宴，因?yàn)?JWT 自包含了用戶信息和加密的數(shù)據(jù)。

常見的前后端鑒權(quán)方式

Session-Cookie,Token 驗(yàn)證（包括 JWT爷怀，SSO),OAuth2.0（開放授權(quán)）

常見問(wèn)題

使用 cookie 時(shí)需要考慮的問(wèn)題

因?yàn)榇鎯?chǔ)在客戶端阻肩，容易被客戶端篡改，使用前需要驗(yàn)證合法性

不要存儲(chǔ)敏感數(shù)據(jù)霉撵，比如用戶密碼磺浙，賬戶余額

使用 httpOnly 在一定程度上提高安全性

盡量減少 cookie 的體積，能存儲(chǔ)的數(shù)據(jù)量不能超過(guò) 4kb

設(shè)置正確的 domain 和 path徒坡，減少數(shù)據(jù)傳輸

cookie 無(wú)法跨域

一個(gè)瀏覽器針對(duì)一個(gè)網(wǎng)站最多存 20 個(gè)Cookie，瀏覽器一般只允許存放 300 個(gè)Cookie

移動(dòng)端對(duì) cookie 的支持不是很好瘤缩，而 session 需要基于 cookie 實(shí)現(xiàn)喇完，所以移動(dòng)端常用的是 token

使用 session 時(shí)需要考慮的問(wèn)題

將 session 存儲(chǔ)在服務(wù)器里面，當(dāng)用戶同時(shí)在線量比較多時(shí)剥啤，這些 session 會(huì)占據(jù)較多的內(nèi)存锦溪，需要在服務(wù)端定期的去清理過(guò)期的 session

當(dāng)網(wǎng)站采用集群部署的時(shí)候，會(huì)遇到多臺(tái) web 服務(wù)器之間如何做 session 共享的問(wèn)題府怯。因?yàn)?session 是由單個(gè)服務(wù)器創(chuàng)建的刻诊，但是處理用戶請(qǐng)求的服務(wù)器不一定是那個(gè)創(chuàng)建 session 的服務(wù)器，那么該服務(wù)器就無(wú)法拿到之前已經(jīng)放入到 session 中的登錄憑證之類的信息了牺丙。

當(dāng)多個(gè)應(yīng)用要共享 session 時(shí)则涯，除了以上問(wèn)題，還會(huì)遇到跨域問(wèn)題冲簿，因?yàn)椴煌膽?yīng)用可能部署的主機(jī)不一樣粟判，需要在各個(gè)應(yīng)用做好 cookie 跨域的處理。

sessionId 是存儲(chǔ)在 cookie 中的峦剔，假如瀏覽器禁止 cookie 或不支持 cookie 怎么辦档礁？一般會(huì)把 sessionId 跟在 url 參數(shù)后面即重寫 url，所以 session 不一定非得需要靠 cookie 實(shí)現(xiàn)

移動(dòng)端對(duì) cookie 的支持不是很好吝沫，而 session 需要基于 cookie 實(shí)現(xiàn)呻澜，所以移動(dòng)端常用的是 token

使用 token 時(shí)需要考慮的問(wèn)題

如果你認(rèn)為用數(shù)據(jù)庫(kù)來(lái)存儲(chǔ) token 會(huì)導(dǎo)致查詢時(shí)間太長(zhǎng)递礼，可以選擇放在內(nèi)存當(dāng)中。比如 redis 很適合你對(duì) token 查詢的需求羹幸。

token 完全由應(yīng)用管理宰衙，所以它可以避開同源策略

token 可以避免 CSRF 攻擊(因?yàn)椴恍枰?cookie 了)

移動(dòng)端對(duì) cookie 的支持不是很好，而 session 需要基于 cookie 實(shí)現(xiàn)睹欲，所以移動(dòng)端常用的是 token

使用 JWT 時(shí)需要考慮的問(wèn)題

因?yàn)?JWT 并不依賴 Cookie 的供炼，所以你可以使用任何域名提供你的 API 服務(wù)而不需要擔(dān)心跨域資源共享問(wèn)題（CORS）

JWT 默認(rèn)是不加密，但也是可以加密的窘疮。生成原始 Token 以后袋哼，可以用密鑰再加密一次。

JWT 不加密的情況下闸衫，不能將秘密數(shù)據(jù)寫入 JWT涛贯。

JWT 不僅可以用于認(rèn)證，也可以用于交換信息蔚出。有效使用 JWT弟翘，可以降低服務(wù)器查詢數(shù)據(jù)庫(kù)的次數(shù)。

JWT 最大的優(yōu)勢(shì)是服務(wù)器不再需要存儲(chǔ) Session骄酗，使得服務(wù)器認(rèn)證鑒權(quán)業(yè)務(wù)可以方便擴(kuò)展稀余。但這也是 JWT 最大的缺點(diǎn)：由于服務(wù)器不需要存儲(chǔ) Session 狀態(tài)，因此使用過(guò)程中無(wú)法廢棄某個(gè) Token 或者更改 Token 的權(quán)限趋翻。也就是說(shuō)一旦 JWT 簽發(fā)了睛琳，到期之前就會(huì)始終有效，除非服務(wù)器部署額外的邏輯踏烙。

JWT 本身包含了認(rèn)證信息师骗，一旦泄露，任何人都可以獲得該令牌的所有權(quán)限讨惩。為了減少盜用辟癌，JWT的有效期應(yīng)該設(shè)置得比較短。對(duì)于一些比較重要的權(quán)限荐捻，使用時(shí)應(yīng)該再次對(duì)用戶進(jìn)行認(rèn)證黍少。

JWT 適合一次性的命令認(rèn)證，頒發(fā)一個(gè)有效期極短的 JWT靴患，即使暴露了危險(xiǎn)也很小仍侥，由于每次操作都會(huì)生成新的 JWT，因此也沒必要保存 JWT鸳君，真正實(shí)現(xiàn)無(wú)狀態(tài)农渊。

為了減少盜用，JWT 不應(yīng)該使用 HTTP 協(xié)議明碼傳輸，要使用 HTTPS 協(xié)議傳輸砸紊。