http協(xié)議本身是無狀態(tài)的,但是在實(shí)際的web開發(fā)中常有一些操作需要有狀態(tài).比如想要訪問一些私人訪問權(quán)限的文章,或者這種操作需要明確當(dāng)前用戶身份.

顯然,最簡(jiǎn)單的方案就是每次都發(fā)送賬戶和密碼,但是這樣重復(fù)操作用用戶并不友好,對(duì)服務(wù)器頁(yè)增添了額外的壓力.為了解決無狀態(tài)帶來的鑒權(quán)問題,一般有以下幾種解決方案:cookie、session、token.至于標(biāo)題中提及的outh2、jwt本質(zhì)上也是token方案.

cookie

Cookie是儲(chǔ)存在客戶端的一串字符,一般說來大小不超過4kb.比如我們常見的記住密碼功能,或者一些基于之前輸入的提醒和默認(rèn)配置,就是通過cookie來實(shí)現(xiàn)的,cookie簡(jiǎn)單說來就是一種本地存儲(chǔ)方法.但是這里存儲(chǔ)的信息常用來進(jìn)行鑒權(quán)操作.cookie只能保存文本信息,瀏覽器可以禁止cookie.cookie的期限可以被自由設(shè)定,可以是僅僅一次瀏覽起效,也可以長(zhǎng)達(dá)一年.如果是短期的,那么這些信息會(huì)被存儲(chǔ)在內(nèi)存中,如果是長(zhǎng)期則會(huì)存儲(chǔ)在硬盤上.cookie的起效范圍是路徑下的所有子路徑.不允許其他來源的訪問.

單純的采用cookie來認(rèn)證身份會(huì)帶來一個(gè)比較麻煩的問題,就是偽造比較容易.因?yàn)檫@樣處理,cookie中必然要帶有身份信息,但是服務(wù)器也要解析這個(gè)身份信息,所以必然要在原理上支持雙向的編碼和解碼,那么這個(gè)信息很容易被破解和進(jìn)一步偽造.想一想,如果想要解決這個(gè)問題,我們常用的方案應(yīng)該是加一個(gè)secret,而這個(gè)secret應(yīng)該是放在服務(wù)器上的,服務(wù)器返回這樣一個(gè)帶有secret編碼的字符串,而在服務(wù)器端再帶上這個(gè)secret反向解密,如此一來,問題不就解決了嗎確實(shí)如此,但是這不代表cookie就安全,因?yàn)檫@已經(jīng)不叫cookie了,而是我們要講的第二個(gè)對(duì)象:session.

session

通過上面說的東西,我們已經(jīng)能夠獲得身份信息,額外的,我們還可以把更復(fù)雜形式的信息都存儲(chǔ)進(jìn)來,因?yàn)檫@里沒有cookie的純文本限制.但是剛才說的帶有secret編碼的字符串也就是sessionid,依然要存儲(chǔ)在客戶端.是不是意味著session必定要依賴cookie呢不是!想一想,我們實(shí)際上需要的是在每一次請(qǐng)求(至少是需要判定身份狀態(tài)的請(qǐng)求中),都帶上這個(gè)字符串,我們有以下這幾種解決方案:

cookie 表單隱藏字段:在form中放置一個(gè)隱藏的域 url重寫:在url后邊加上session的query段

Session也可以設(shè)定有效時(shí)間.其實(shí)際的存儲(chǔ)可以在內(nèi)存、緩存、文件中.通過類似//可能具體實(shí)現(xiàn)不同.//hash表的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ).cookie是一個(gè)存在的實(shí)體,session是一種機(jī)制.

token

對(duì)token的理解還不夠,可能多有紕漏之處,待之后再進(jìn)行修改.

使用基于 Token 的身份驗(yàn)證方法，在服務(wù)端不需要存儲(chǔ)用戶的登錄記錄。大概的流程是這樣的：

客戶端使用用戶名跟密碼請(qǐng)求登錄 服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼 驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè) Token，再把這個(gè) Token 發(fā)送給客戶端
客戶端收到 Token 以后可以把它存儲(chǔ)起來，比如放在 Cookie 里或者 Local Storage 里 客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的 Token 服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的 Token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)

可以看出來,這里的token與sessionid有些類似,其區(qū)別:

sessionid是帶著之前的狀態(tài)的,在服務(wù)器端可以getSession(sessionid) token是在登錄驗(yàn)證之后發(fā)放的一個(gè)包含著用戶基本信息的較長(zhǎng)的字符串,用處是驗(yàn)證身份以及簡(jiǎn)化后續(xù)獲取信息的難度. token機(jī)制更靈活,可以實(shí)現(xiàn)跨域

jwt

Jwt簡(jiǎn)單說來是一種token的具體實(shí)現(xiàn)規(guī)范!

Jwt標(biāo)準(zhǔn)的token有三個(gè)部分,中間用點(diǎn)分隔開，并且都會(huì)使用 Base64 編碼:

header。header 部分主要是兩部分內(nèi)容，一個(gè)是 Token 的類型，另一個(gè)是使用的算法 Payload。里面是 Token 的具體內(nèi)容，這些內(nèi)容里面有一些是標(biāo)準(zhǔn)字段，你也可以添加其它需要的內(nèi)容 Signature。編碼以上兩個(gè)部分并且加入一個(gè)secret使用信息摘要算法得出一個(gè)字符串

oauth2

簡(jiǎn)單來說,oauth是用來向第三方平臺(tái)提供可以細(xì)致的權(quán)限管理的一種方案.
如何直接向第三方提供賬號(hào)和密碼,可能存在的問題有:

不安全 無法更細(xì)致的限制授權(quán)范圍和有效期 只有修改密碼才能收回權(quán)限 一個(gè)第三方程序被破解將會(huì)導(dǎo)致用戶密碼泄漏

OAuth的基本思路如下:

OAuth在”客戶端”與”服務(wù)提供商”之間，設(shè)置了一個(gè)授權(quán)層（authorization layer）。”客戶端”不能直接登錄”服務(wù)提供商”，只能登錄授權(quán)層，以此將用戶與客戶端區(qū)分開來。”客戶端”登錄授權(quán)層所用的令牌（token），與用戶的密碼不同。用戶可以在登錄的時(shí)候，指定授權(quán)層令牌的權(quán)限范圍和有效期。”客戶端”登錄授權(quán)層以后，”服務(wù)提供商”根據(jù)令牌的權(quán)限范圍和有效期，向”客戶端”開放用戶儲(chǔ)存的資料。