token與sessionId的區別——學習筆記

學開發半年多，以前一直有個疑問：
爲何要用token，好好的用sessionID很差嗎
（其實就是新技術與老技術，可是仍是想弄懂）
這個問題以前一直疑惑，今天搞懂了，整合了一下學習過程，先對比一下sessionID與token

1、簡述sessionID的生成方式與token的生成方式

1.sessionID的生成方式

瀏覽器第一次訪問服務器時，服務器建立一個session，同時生成一個惟一的會話key，即sessionID。接着sessionID及session分別做爲key和value保存到緩存中，也能夠保存到數據庫中，而後服務器把sessionID以cookie的形式發送給瀏覽器，瀏覽器下次訪問服務器時直接攜帶上cookie中的sessionID，服務器再根據sessionID找到對應的session進行匹配
這裏咱們注意到兩點：1.sessionID會自動由瀏覽器帶上 2.session是須要存儲空間的

2.token的生成方式

瀏覽器第一次訪問服務器時，服務器根據傳過來的惟一標識userId，經過一些算法，加一個密鑰，生成一個token，接着經過base64編碼將token返回給客戶端。客戶端將token保存起來，下次請求時須要帶着token，服務器收到請求後，用相同的算法和密鑰去驗證token
這裏咱們注意到兩點：1.token須要代碼才能帶上 2.token能夠不須要存儲空間（JWT）（固然也有存入緩存的處理，特別是要進行revoke操做時），經過算法和密鑰驗證

3.區別

以上咱們提出來的注意點就能夠看出兩點區別了：1.瀏覽器方面，是否直接帶上 2.服務器方面，是否須要存儲空間。

二.回答以前的疑問

1.安卓，ios，微信小程序，微信內置瀏覽器上

安卓與ios用原生接口發請求時，每一次建立一個會話（C/S模式）
https://blog.csdn.net/qq_4219...
https://www.cnblogs.com/liuji...

微信小程序經過微信官方提供的登陸能力獲取微信提供的用戶身份標識，快速創建小程序內的用戶體系
https://developers.weixin.qq....

微信內置瀏覽器會對全部請求作代理，致使出去的ip不固定
https://blog.csdn.net/wangjun...

2.安全問題上，防止CSRF攻擊

（原來瀏覽器加載image標籤中的地址也會發送sessionID的）
這裏對技術機制沒有透徹的瞭解，不敢隨意翻譯而誤導，你們看一下如下的段落吧
摘自https://guides.rubyonrails.or...
Cross-Site Request Forgery (CSRF)
This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands.
In the session chapter you have learned that most Rails applications use cookie-based sessions. Either they store the session ID in the cookie and have a server-side session hash, or the entire session hash is on the client-side. In either case the browser will automatically send along the cookie on every request to a domain, if it can find a cookie for that domain. The controversial point is that if the request comes from a site of a different domain, it will also send the cookie. Let's start with an example:

Bob browses a message board and views a post from a hacker where there is a crafted HTML image element. The element references a command in Bob's project management application, rather than an image file: <img src="http://www.webapp.com/project...;>

Bob's session at www.webapp.com is still alive, because he didn't log out a few minutes ago.
By viewing the post, the browser finds an image tag. It tries to load the suspected image from www.webapp.com. As explained before, it will also send along the cookie with the valid session ID.
The web application at www.webapp.com verifies the user information in the corresponding session hash and destroys the project with the ID 1. It then returns a result page which is an unexpected result for the browser, so it will not display the image.
Bob doesn't notice the attack - but a few days later he finds out that project number one is gone.

It is important to notice that the actual crafted image or link doesn't necessarily have to be situated in the web application's domain, it can be anywhere - in a forum, blog post or email.
CSRF appears very rarely in CVE (Common Vulnerabilities and Exposures) - less than 0.1% in 2006 - but it really is a 'sleeping giant' [Grossman]. This is in stark contrast to the results in many security contract works - CSRF is an important security issue.

三.總結

廣義上來講一切維護用戶狀態的技術都是session，而後sessionid與token就是老技術與技術
但是就是想知道爲何
以上內容若有不對請指出

參考資料：

Session,Token相關區別：https://www.cnblogs.com/xiaoz...
基於 Token 的身份驗證：JSON Web Token（附：Node.js 項目）：https://ninghao.net/blog/2834
基於 session 和基於 token 的用戶認證方式到底該如何選擇？：https://www.v2ex.com/t/276207
我想知道token和sessionid的區別是什麼：https://www.v2ex.com/t/80003
爲何 APP 要用 token 而不用 session 認證？：https://www.v2ex.com/t/148426
移動端開發爲何不採用session而是用token：https://www.zhihu.com/questio...