Session、Token、Jwt三种登录方案介绍

新开发一个应用首先要考虑的就是登录怎么去做，登录本身就是判断一下输入的用户名和密码与系统存储的是否一致，但因为Http是无状态协议，用户请求其它接口时是怎么判断该用户已经登录了呢？下面聊一个三种实现方案。

一、传统session方案

这种方案在以前前后端架构不分离的时候采用的，基于客户端Cookie和服务端Session来做，基本流程如下

1、用户登录成功后查询数据库取出用户信息放到Session中。

2、服务端往客户端浏览器写Cookie，Cookie里存放加密的用户名，一般用3DES搞搞就可以，如果是非交易网站，甚至有直接明文或只做一下Base64.

3、用户请求接口时浏览器会把Cookie发送给服务端，服务端拿到这个Cookie解析出用户名，然后根据用户名获取Session里用户对象信息.

4、如果应用部署在多台服务器，需要做Session同步，这里一般有两种做法，一种是通过容器（Tomcat）本身进行Session复制，但存在一个问题，当用户量大的时候，每台服务器重复存放大量的Session对象，会占用大量的内存，另外一种做法是写一个拦截器，用户在A机器登录后会在当前服务器生成Session，然后用户下一个请求被路由到机器B，这时需要做Session的恢复，解析出Cookie中用户名查找到用户数据然后放到Session里去，该用户下次请求如果还是路由到该台机器就不用再查数据库了。

缺点

1、Session存在内存中，用户多会占用大量应用服务器的内存.

2、Cookie安全性，如果Cookie被截获，很容易造成跨站请求伪造脚本攻击.

3、前后端分离的应用无法使用Cookie

PS:十几年前跟着大牛做过这个事情，在整理文章时，花了点时间才慢慢回忆起来。

二、token+redis方案

当前公司的收银系统采用的就是该方案，具体实现流程如下：

1、用户登录成功后生成一个Token，Token的生成依赖于Linux系统的urandom，然后将token和查询出来的用户对象数据存到redis中 token做为key，value存用户对象，并将token返回给客户端，redis设置过期时间12小时。

cat /dev/urandom |od -x | tr -d ' '| head -n 1

2、客户端拿到Token，存到localStorage里，然后写一个通用的请求拦截,在每次请求时http头加上token值。

3、服务端写一个注解NeedLogin，需要登录的接口加上该注解.

4、服务端写一个拦截器，判断请求的方法上有没有加NeedLogin注解，如果没有注解则返回，如果有注解则从Http请求头中把Token拿出来，判断该Token是否存在，存在则认为是处于登录状态的。

5、接口调用时需要根据Token值从Redis中获取用户对象数据

优缺点：服务端可以主动让Token失效，但用户信息存在Redis占用一定空间并且需要一次redis查找(PS：好像不不算什么缺点)，属于中心化方案。

三、Jwt方式

当前公司在线窗帘定制网站采用的是该方案，Jwt即Json Web Token，实现流程和Token方案基本一样，区别在于用户信息保存在Jwt中，客户端每次请求都会把Jwt带过来，服务端从Jwt解析出用户对象数据。

Jwt的组成

• header：声明类型及签名算法，做Base64。

• playload: 包括注册的声明（签发时间/过期时间/面向的用户）、公共和私有声明，内容也仅只做Base64编码.

• sign：base64（header)+base64(playload)+secret

优缺点：该方案跨语言、另外payload可以存放非敏感用户数据以减少数据库或缓存查询、它不需要服务端保存会话信息、应用易于扩展、但服务端无法主动让Jwt失效，因为数据安全性尽可能使用https协议。