文章目录
1. JWT 产生背景
客户端通过调用服务端的接口,访问服务端业务数据,但是,一般的数据并非所有的用户都有权限去访问。因此,为了保证数据的安全性,在访问者访问数据时需要验证此次请求是否有足够的权限去访问此数据,也就是对访问者进行鉴权。
由于HTTP
协议是无状态的,也就是说,如果我们已经认证了一个用户,那么他下一次请求的时候,服务器不知道我是谁,所以这就导致我们必须再次认证。
为了解决以上问题,目前有两种方式,如下:
- 基于服务器的身份认证
- 基于Token的身份认证
1.1 传统基于服务的认证方式
传统的做法是将已经认证过的用户信息存储在服务器上,比如Session
。用户下次请求的时候带着Session ID
,然后服务器以此检查用户是否认证过。
基于服务的认证方式的不足
- Sessions:用户通过认证之后,服务对就会为其创建一个session存放在服务端,通常会放到服务器的内存之中,这无形之中给服务器增加了负担,开销会越来越大。
- 扩展性:每一个用户认证同过,对应的
session
信息就会存在放在认证服务器的内存之中,如果在集群部署的情况下,在没有使用ip_hash
的情况下,会出现一些重复登录的问题。 - CORS:在移动端发展如此迅猛的情况下,往往是一套后端服务,支持多种前端设备,尤其是我们的数据被多个移动端使用的情况,这时我们就必须要考虑跨域资源共享的问题了。或者当使用
ajax
从另一个域名下调用服务资源时,我们可能会遇到禁止请求的问题。 - CSRF:是的用户容易遭到
CSRF
攻击。
1.2 基于Token的身份认证
基于Token的身份认证是无状态的,所以在服务器端或session中不会存储任何与用户有关的信息。这样也很好的解决了服务的集群部署问题,即使部署多台服务器,因为每个服务都不需要存储用户信息,所以服务可以根据需求进行横向扩展。
认证流程实现
- 用户使用用户名和密码请求登录认证
- 服务器端根据用户提供的用户名和密码进行验证;
- 认证成功之后,服务器端生成用户唯一标识的
token
返回; - 客户端保存服务器端返回的
token
,并在随后的每一次请求中,携带此token
; - 客户端携带
token
访问服务器端接口,服务器端验证token
,验证成功则访问数据,验证失败则直接返回提示。
基于Token的认证方式的优点
- 无状态支持扩展:由于服务器端不存储用户登录的状态,有关用户登录的数据信息皆存在客户端,每次请求时携带用户登录信息。因此负载均衡器可以将用户的请求分配到任何一个后台不服务器上去处理请求数据。
- 避免
CSRF
攻击:token
常常被放到 HTTP Header 中,因此并不需要携带Cookie。当然,你也可以将token
放到Cookie中,但是此时的Cookie只是一个存储机制,而非基于Cookie的认证机制。
JWT就是一种有效的,基于Token的身份认证方式。
2. JWT 简介
2.1 JWT 是什么
from:JWT 官方简介
get the JWT Handbook for free and learn JWTs in depth!