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...