Session 与 Token 的区别

╰半橙微兮° 2022-03-22 11:50 196阅读 0赞

1. 为什么要有session的出现？  
答：是由于网络中http协议造成的，因为http本身是无状态协议，这样，无法确定你的本次请求和上次请求是不是你发送的。如果要进行类似论坛登陆相关的操作，就实现不了了。

2. session生成方式？  
答：浏览器第一次访问[服务器][Link 1]，服务器会创建一个session，然后同时为该session生成一个唯一的会话的key,也就是sessionid，然后，将sessionid及对应的session分别作为key和value保存到缓存中，也可以持久化到数据库中，然后服务器再把sessionid，以cookie的形式发送给客户端。这样浏览器下次再访问时，会直接带着cookie中的sessionid。然后服务器根据sessionid找到对应的session进行匹配；  
还有一种是浏览器禁用了cookie或不支持cookie，这种可以通过URL重写的方式发到服务器；

简单来讲，用户访问的时候说他自己是张三，他骗你怎么办？ 那就在服务器端保存张三的信息，给他一个id，让他下次用id访问。

3. 为什么会有token的出现？  
答：首先，session的存储是需要空间的，其次，session的传递一般都是通过cookie来传递的，或者url重写的方式；而token在服务器是可以不需要存储用户的信息的，而token的传递方式也不限于cookie传递，当然，token也是可以保存起来的；

4. token的生成方式？  
答：浏览器第一次访问服务器，根据传过来的唯一标识userId，服务端会通过一些算法，如常用的HMAC-SHA256算法，然后加一个密钥，生成一个token，然后通过BASE64编码一下之后将这个token发送给客户端；客户端将token保存起来，下次请求时，带着token，服务器收到请求后，然后会用相同的算法和密钥去验证token，如果通过，执行业务操作，不通过，返回不通过信息；

5. token和session的区别？  
token和session其实都是为了身份验证，session一般翻译为会话，而token更多的时候是翻译为令牌；  
session服务器会保存一份，可能保存到缓存，文件，数据库；同样，session和token都是有过期时间一说，都需要去管理过期时间；  
其实token与session的问题是一种时间与空间的博弈问题，session是空间换时间，而token是时间换空间。两者的选择要看具体情况而定。

虽然确实都是“客户端记录，每次访问携带”，但 token 很容易设计为自包含的，也就是说，后端不需要记录什么东西，每次一个无状态请求，每次解密验证，每次当场得出合法 /非法的结论。这一切判断依据，除了固化在 CS 两端的一些逻辑之外，整个信息是自包含的。这才是真正的无状态。   
而 sessionid ，一般都是一段随机字符串，需要到后端去检索 id 的有效性。万一服务器重启导致内存里的 session 没了呢？万一 redis 服务器挂了呢？   
  
方案 A ：我发给你一张身份证，但只是一张写着身份证号码的纸片。你每次来办事，我去后台查一下你的 id 是不是有效。   
方案 B ：我发给你一张加密的身份证，以后你只要出示这张卡片，我就知道你一定是自己人。   
就这么个差别。

token的使用可以参考：json web token(JWT);

参考自：https://www.v2ex.com/t/80003

https://www.v2ex.com/t/276207

https://ninghao.net/blog/2834

本文转载自：https://www.cnblogs.com/xiaozhang2014/p/7750200.html

补充：

什么是token

token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。

当用户第一次登录后，服务器生成一个token并将此token返回给客户端，以后客户端只需带上这个token前来请求数据即可，无需再次带上用户名和密码。

简单token的组成；uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token的前几位以哈希算法压缩成的一定长度的十六进制字符串。为防止token泄露）。

身份认证概述

由于HTTP是一种没有状态的协议，它并不知道是谁访问了我们的应用。这里把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下次这个客户端再发送请求时候，还得再验证一下。

通用的解决方法就是，当用户请求登录的时候，如果没有问题，在服务端生成一条记录，在这个记录里可以说明登录的用户是谁，然后把这条记录的id发送给客户端，客户端收到以后把这个id存储在cookie里，下次该用户再次向服务端发送请求的时候，可以带上这个cookie，这样服务端会验证一下cookie里的信息，看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。

以上所描述的过程就是利用session，那个id值就是sessionid。我们需要在服务端存储为用户生成的session，这些session会存储在内存，磁盘，或者数据库。

基于token机制的身份认证

使用token机制的身份验证方法，在服务器端不需要存储用户的登录记录。大概的流程：

客户端使用用户名和密码请求登录。服务端收到请求，验证用户名和密码。验证成功后，服务端会生成一个token，然后把这个token发送给客户端。客户端收到token后把它存储起来，可以放在cookie或者Local Storage（本地存储）里。客户端每次向服务端发送请求的时候都需要带上服务端发给的token。服务端收到请求，然后去验证客户端请求里面带着token，如果验证成功，就向客户端返回请求的数据。

利用token机制进行登录认证，可以有以下方式：

a.用设备mac地址作为token

客户端：客户端在登录时获取设备的mac地址，将其作为参数传递到服务端

服务端：服务端接收到该参数后，便用一个变量来接收，同时将其作为token保存在数据库，并将该token设置到session中。客户端每次请求的时候都要统一拦截，将客户端传递的token和服务器端session中的token进行对比，相同则登录成功，不同则拒绝。

此方式客户端和服务端统一了唯一的标识，并且保证每一个设备拥有唯一的标识。缺点是服务器端需要保存mac地址；优点是客户端无需重新登录，只要登录一次以后一直可以使用，对于超时的问题由服务端进行处理。

b.用sessionid作为token

客户端：客户端携带用户名和密码登录

服务端：接收到用户名和密码后进行校验，正确就将本地获取的sessionid作为token返回给客户端，客户端以后只需带上请求的数据即可。

此方式的优点是方便，不用存储数据，缺点就是当session过期时，客户端必须重新登录才能请求数据。

当然，对于一些保密性较高的应用，可以采取两种方式结合的方式，将设备mac地址与用户名密码同时作为token进行认证。

APP利用token机制进行身份认证

用户在登录APP时，APP端会发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果验证成功，就会生成相应位数的字符产作为token存储到服务器中，并且将该token返回给APP端。

以后APP再次请求时，凡是需要验证的地方都要带上该token，然后服务器端验证token，成功返回所需要的结果，失败返回错误信息，让用户重新登录。其中，服务器上会给token设置一个有效期，每次APP请求的时候都验证token和有效期。

token的存储

token可以存到数据库中，但是有可能查询token的时间会过长导致token丢失（其实token丢失了再重新认证一个就好，但是别丢太频繁，别让用户[没事儿][Link 2]就去认证）。

为了避免查询时间过长，可以将token放到内存中。这样查询速度绝对就不是问题了，也不用太担心占据内存，就算token是一个32位的字符串，应用的用户量在百万级或者千万级，也是占不了多少内存的。

token的加密

token是很容易泄露的，如果不进行加密处理，很容易被恶意拷贝并用来登录。加密的方式一般有：

在存储的时候把token进行对称加密存储，用到的时候再解密。文章最开始提到的签名sign：将请求URL、时间戳、token三者合并，通过算法进行加密处理。

最好是两种方式结合使用。

还有一点，在网络层面上token使用明文传输的话是非常危险的，所以一定要使用HTTPS协议。

参考：http://baijiahao.baidu.com/s?id=1586852093066659408&wfr=spider&for=pc

转载：[https://blog.csdn.net/love\_onefly/article/details/80738888][https_blog.csdn.net_love_onefly_article_details_80738888]

[Link 1]: https://www.baidu.com/s?wd=%E6%9C%8D%E5%8A%A1%E5%99%A8&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[Link 2]: https://www.baidu.com/s?wd=%E6%B2%A1%E4%BA%8B%E5%84%BF&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd
[https_blog.csdn.net_love_onefly_article_details_80738888]: https://blog.csdn.net/love_onefly/article/details/80738888