現(xiàn)在隨著客戶端的多樣化、前端的不斷發(fā)展，傳統(tǒng)的基于cookie的會(huì)話控制限制越來(lái)越多。cookie的跨域問(wèn)題，移動(dòng)端native app 對(duì)于cookie支持的缺失。今天就來(lái)看下另一種解決方案。
用戶認(rèn)證的本質(zhì)
用戶認(rèn)證分為會(huì)話控制(authentication)和權(quán)限控制(authorization)。要實(shí)現(xiàn)會(huì)話控制，就需要一個(gè)身份認(rèn)證的過(guò)程：
1.客戶端提供認(rèn)證憑證。eg：username password
2.服務(wù)器核對(duì)。
3.核對(duì)失敗則返回失敗信息。核對(duì)成功則返回成功標(biāo)識(shí)，傳統(tǒng)的方式是使用session，設(shè)置客戶端cookie。
4.客戶端請(qǐng)求需要認(rèn)證的網(wǎng)址。傳統(tǒng)的方式是由瀏覽器自動(dòng)發(fā)送cookie到服務(wù)器端，服務(wù)器端核對(duì)sessionid。
基于token的認(rèn)證系統(tǒng)
優(yōu)點(diǎn)
基于token的認(rèn)證系統(tǒng)解決了什么問(wèn)題呢？
Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX calls to any server, on any domain because you use an HTTP header to transmit the user information.
Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contanined entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.
CDN: you can serve all the assets of your app from a CDN (e.g. javascript, HTML, images, etc.), and your server side is just the API.
Decoupling: you are not tied to a particular authentication scheme. The token might be generated anywhere, hence your API can be called from anywhere with a single way of authenticating those calls.
Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a secure API (you have to deal with cookie containers). Adopting a token-based approach simplifies this a lot.
CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to <iframe>
your site, generate a POST request and re-use the existing authentication cookie because there will be none).
Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database) is likely to take more time than calculating an HMACSHA256
to validate a token and parsing its contents.
Login page is not an special case: If you are using Protractor to write your functional tests, you don't need to handle any special case for login.
Standard-based: your API could accepts a standard JSON Web Token (JWT). This is a standard and there are multiple backend libraries (.NET, Ruby, Java,Python, PHP) and companies backing their infrastructure (e.g. Firebase, Google,Microsoft). As an example, Firebase allows their customers to use any authentication mechanism, as long as you generate a JWT with certain pre-defined properties, and signed with the shared secret to call their API.
可以看到token解決了以下問(wèn)題
- 跨域。ajax設(shè)置"Authorization header" and "Bearer。
- 狀態(tài)無(wú)關(guān)。天然適合restful services。
- CDN。 專注api。
- 解耦。token可以隨時(shí)生成，隨處驗(yàn)證。
- 移動(dòng)適用。移動(dòng)端cookie支持不好。
- CSRF。這個(gè)需要具體情況具體分析。
- 性能。連接數(shù)據(jù)庫(kù)查詢session比對(duì)token進(jìn)行解密更費(fèi)時(shí)間。
- 標(biāo)準(zhǔn)化。 JSON WEB TOKEN (JWT) http://jwt.io/
區(qū)別
缺點(diǎn)
token存儲(chǔ)、傳輸。
- 對(duì)于reftful 客戶端， 將其設(shè)置成GET或POST參數(shù)即可。
- 對(duì)于傳統(tǒng)web。可存儲(chǔ)在cookie里由瀏覽器自動(dòng)傳送，會(huì)有跨域問(wèn)題。
- 或者存儲(chǔ)在localsotrage里, 或者url里，或者放在頁(yè)面里。需要用js手動(dòng)取出，拼接到url里。這會(huì)加大工作量。適用范圍有限。
- 利用"Authorization header" and "Bearer。
Accept:application/json, text/plain, /
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6,ja;q=0.4
Authorization:Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmaXJzdF9uYW1lIjoiSm9obiIsImxhc3RfbmFtZSI6IkRvZSIsImVtYWlsIjoiam9obkBkb2UuY29tIiwiaWQiOjEyMywiaWF0IjoxNDMwMDI2MzI0LCJleHAiOjE0MzAwNDQzMjR9.wODsE0vHiGr8RruRppJ79JKqH_Fi_2QUBxNJDzM_nfY
Connection:keep-alive
Host:localhost:8080
If-None-Match:W/"e-87842b1a"
Referer:http://localhost:8080/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.90 Safari/537.36
總結(jié)
本質(zhì)上cookie和token在客戶端的方式并沒(méi)有區(qū)別。都是提供了一種認(rèn)證信息傳輸?shù)姆绞健?/p>
請(qǐng)關(guān)注后續(xù)文章_
