学开发半年多，之前一直有个疑问：
为什么要用token，好好的用sessionID不好吗
（其实就是新技术与老技术，但是还是想弄懂）
这个问题之前一直疑惑，今天搞懂了，整合了一下学习过程，先对比一下sessionID与token
一、简述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...