【开发】session和token的使用

爱好怪奇的奈斯

于 2024-08-07 20:45:43 发布

阅读量570

点赞数 6

分类专栏：开发文章标签： java 开发语言后端

本文链接：https://blog.csdn.net/m0_73455589/article/details/140999488

版权

开发专栏收录该内容

1 篇文章 0 订阅

订阅专栏

浅聊一下，适合初学者~

这篇纯理论，比较长，慢慢看 > . <

需要有一点点redis的基础，比如知道redis是键值对数据库哦~

前言

先简单介绍一下cookie

cookie在客户端上，用于保存服务端发送的数据。服务端通过set-cookie将数据存到客户端。

然后往下吧

正篇

session和token都是使用在鉴权场景下。

当你要访问系统中的某些资源时，就需要登录才能进行访问。

如果你已经是在登录状态了，那你就有权限进行访问。

大家都知道通过账号密码进行登录，所以账号密码输入正确，逻辑上你就有权限进行访问系统了。但是当你再发送一次请求时，由于http是无状态的协议，不会标识你的登录状态，那怎么证明你已经登录过了呢？

这时候就需要服务端在你完成登录后，给客户端发一个凭证，等下次访问时，客户端携带上这个凭证，服务端队凭证校验过后，没问题，就给你访问相应的资源。

这个凭证是有过期时间的，不知道大家有没有注意到，当你很长一段时间没有使用某个网站时，你就需要重新登录呢？那是因为如果凭证长期有效，容易被别人盗取，从而通过这个凭证获取你在网站上的个人信息，是一个安全性的考虑。

上文提到的凭证，有两种形式。

一种就是session

session

当你输入账号密码经过校验成功后，服务端会开辟一个空间session（容器），用来存储你的个人信息，然后返回给客户端一个sessionId存储在cookie中。当客户端下次发送请求时，会携带上这个cookie。

服务端通过获取cookie，也就是传来的sessionId去获取用户信息，如果用户信息存在，则放行，可以访问其他资源，如果没有获取到，就拒绝请求，或者跳转到登录页面。

分布式session

那在分布式场景下，有多台服务器，用户的请求会被负载均衡到多台服务器上，那就可能出现这种情况，登录时，访问的是服务器A，所以用户信息存在服务器A上，而请求资源时访问的是服务器B，显然，用从服务器A上获取到的sessionId来获取用户的信息是获取不到的。

那该怎么解决呢？

一个常见的思路就是把所有的session放到一个服务器上进行存储，每次要校验时，从这个服务器去获取用户信息，获取到了，那就放行。

这就是分布式session的实现。

通常这个服务器是redis，key是sessionId，value就是用户的信息。

鉴权流程就变成了这样：

用户由于没凭证（sessionId），所以系统重定向到了登录页面。输入账号密码校验完之后，服务端A随机生成一串字符作为sessionId，然后将sessionId作为key，用户信息作为value存储到redis中，返回给客户端sessionId。

用户访问某个资源，请求到了服务器B。在请求中获取到sessionId后，从redis去获取对应的用户信息，获取到则放行。

另一种凭证就是token了。

token

token本身携带用户数据，还包括了该token的过期时间。当你登录之后，服务端会根据加密算法，将用户数据和其他信息加密后生成一个token（就是一串字符），发送给客户端（也是存在cookie中，cookie比较好用，服务端在set-cookie时，可以指定cookie的域和路径。当客户端发送请求时，如果请求的域是cookie被指定的域，并且请求路径中包含cookie被指定的路径，这个http请求就会自动携带上这个cookie）

下次发送请求时，携带上这个token，服务端获取到token后，根据加密算法进行解密，获取用户数据进行校验。如果正确则放行，这个就不会有session的分布式问题，因为数据是在token上的，只要服务端能进行解密校验就行了~

token的实现有很多种，常见的有JWT（Json Web Token），可以了解一下

对于安全性要求高的系统，token的时效就会短，但这样会影响用户的体验，时不时就要你重新登录就很烦。

所以就有了双token的方案。