JWT与授权的几种方式对比

一、jwt 的定义

JWT（JSON Web Token）是目前最流行的跨域认证解决方案，是为了网络应用环境之间传递声明而执行的基于JSON的开发标准，该token被设计为紧密安全的，特别适用于分布式站点的单点登录场景。

jwt的声明一般用来在身份提供者和服务提供者之间传递被认证的用户信息，以便从服务器获取到资源。该token可以被用来做认证和加密。

二、 jwt 的使用场景

2.1 授权

最常用的场景，解决登陆问题。

使用优点：开销小、轻便、无状态（服务端不用记录用户状态信息）

授权的几种方式

1、session
2、cookie
3、token+redis
4、jwt / jwt+redis
具体的认证过程请看此文章：
几种常见登录验证的方式总结

以下是我个人在学习时的两个疑惑，网上的博客也会说明，但是通常不是博客的重点，很容易被忽略。

1、session与cookie 单机服务器 vs 服务器集群

实现授权的常用方式：cookie、session

老生常谈的问题，请问cookie和session的区别？现在最常用的是什么？

一看到这个问题，熟悉的同学已经开始在脑子里罗列1234点了，但是它们之间各有区别，但这些缺点、或者优点，不是现在通用方法变迁的主要原因。而是因为硬件的升级、数据访问量的增大，以至于需要将传统的单台服务器升级为分布式服务器。cookie和session适用环境的不同，才是它们变迁的主要原因。

它们之间最明显的区别是session存在服务器端，cookie存在客户端，衍生出来的区别便是：session存在服务器端安全，cookie存在客户端容易被窃取等等。

在单台服务器环境下，好像session更安全，更应该使用。但是在如今分布式服务器的环境下，我们就会发现session并不好用了。

在分布式系统中，往往会有多台服务器来处理同一业务。如果用户在A服务器登录，Session位于A服务器，那么当下次请求被分配到B服务器，将会出现登录失效的问题。

针对类似的场景，有三种解决方案：
1、session信息同步。但这会带来同步的开销和相应的风险，例如同步失败等。
2、请求精确定位。也就是通过负载均衡器让来自同一IP的用户请求始终分配到同一服务上。但这也有一个问题，即违背了使用分布式服务器的要求，即服务均衡负载。单独分一台机子去做单一的功能，会有登录请求在某一时间暴增，服务器因无法处理而崩溃，也会有很长一段时间毫无登录请求而使一台机子闲置的问题，这都不是我们想要的。
3、基于共享缓存。该方案是通过将Session放在一个公共地方，各个服务器使用时去取即可。比如，存放在Redis、Memcached等缓存中间件中。

故此，现在的登录大多使用cookie授权。

2、token+redis 与 jwt / jwt+redis

2.1、jwt中的t，也就是token，那和普通的token有什么区别呢？
一般从jwt的定义出发，就能得到答案。视角转回第一节的定义。

看完定义再回来，这里token和jwt的主要区别我认为是token一般是不携带用户信息的（因为如果携带用户信息，再加上为了安全性做的加密和签名，这不就是jwt了吗hhh），用户信息存储在 Redis 中，在登录请求中，服务器根据请求中携带的 Token 查询 Redis，从中获取用户信息并进行授权等操作。

JWT 自包含所有必要的会话信息（如用户身份、角色、权限等），即使不查询 Redis，服务器也能解码并使用这些信息进行授权。

2.2、那为什么 jwt 一般也配合 Redis 使用？

一般是更多功能的扩展。需要注意的是，JWT Token一旦签发，其内容无法更改，除非新签发一个Token。因此，在设计和使用过程中需要考虑Token的过期时间和刷新机制。

安全控制：
Token + Redis：更容易实现 Token 的撤销、强制下线等功能，因为所有的会话状态都集中管理在 Redis 中。
JWT：实现类似功能需要额外的设计（如使用 Redis 存储黑名单或撤销列表），故此需要 Redis 的协助

2.2 交换信息

用于在各个服务之间安全传递信息，因为jwt可以签名，例如公钥/私钥，可以确定请求是否合法。

此外，由于使用标头和有效负载计算签名，还可以验证内容是否被篡改。

三、原理和流程

参考此文章：
JSON Web令牌(JWT)详解