一文读懂JWT

开发
JWT(JSON Web Token)是目前最流行的跨域认证解决方案,是一种基于Token的认证授权机制。此外JWT还被广发应用于单点登陆及信息交换。

Labs 导读

我们在做应用系统时避免不了用户的认证授权,说简单点就是:认证你是谁,授权你有什么权限。在这里先来谈谈用户的认证,目前常用的认证方式有两种:基于session认证、基于token认证。

Part 01、  JWT是什么?  

JWT(JSON Web Token)是一个开放的行业标准(RFC 7519),自身包含了身份验证所需要的所有信息,因此我们的服务器不需要存储用户Session信息。这显然增加了系统的可用性和伸缩性,大大减轻了服务端的压力。可以看出JWT更符合设计RESTful API时的Stateless(无状态)原则。并且使用JWT认证可以有效避免CSRF攻击,因为JWT一般是存在在localStorage中,使用JWT进行身份验证的过程中是不会涉及到Cookie的。

Part 02、  JWT由哪些部分组成? 

图片图片

JWT本质上是一组字串,通常是这样的:xxxxx.yyyyy.zzzzz,通过(.)切分成三个为Base64编码的部分:

  • Header:描述JWT的元数据,定义了生成签名的算法以及Token的类型。
  • Payload:用来存放实际需要传递的数据。
  • Signature:服务器通过Payload、Header和一个密钥(Secret)

使用Header里面指定的签名算法(默认是 HMAC SHA256)生成。

示例:

图片图片

可以通过https://jwt.io对上述JWT进行解码,解码之后便可得到Header、Payload、Signature这三部分。Header和Payload都是JSON格式的数据,Signature由Payload、Header和Secret(密钥)通过特定的计算公式和加密算法得到。

图片图片

  • Header

通常由两部分组成。

  • typ(Type):令牌类型,也就是JWT
  • alg(Algorithm):签名算法,比如HS256

示例:

图片图片

JSON形式的Header被转换成Base64编码,成为JWT的第一部。

  • Payload

包含了三种类型的声明。

  • Registered Claims(注册声明):预定义的一些声明,建议使用,但不强制。
  • Public Claims(公有声明):JWT签发方可以自定义的声明。
  • Private Claims(私有声明):JWT签发方因为项目需要而自定义的声明。

下面是一些常见的注册声明:

  • iss(issuer):JWT 签发方。
  • iat(issued at time):JWT签发时间。
  • sub(subject):JWT主题。
  • aud(audience):JWT接收方。
  • exp(expiration time):JWT的过期时间。
  • nbf(not before time):JWT生效时间,早于该定义的时间的JWT不能被接受处理。
  • jti(JWT ID):JWT唯一标识。

示例:

图片图片

Payload部分默认是不加密的,一定不要将隐私信息存放在 Payload 当中!!!

JSON 形式的Payload被转换成Base64编码,成为JWT的第二部分。

  • Signature

对前两部分的签名,作用是防止JWT(主要是payload)被篡改。签名的生成需要用到:Header+Payload、存放在服务端的密钥(一定不要泄露出去)、签名算法。签名的计算公式如下:

图片图片

算出签名以后,把 Header、Payload、Signature三个部分拼成一个字符串,每个部分之间用"点"(.)分隔,这个字符串就是JWT。

Part 03、 JWT如何进行用户认证?

在基于JWT进行身份验证的的应用程序中,服务器通过 Payload、Header和Secret(密钥)创建JWT并将JWT发送给客户端。客户端接收到JWT之后,会将其保存在Cookie或者localStorage里面,以后客户端发出的所有请求都会携带这个令牌。

图片图片

简化后的步骤如下:

1.用户向服务器发送用户名、密码以及验证码用于登陆系统。

2.如果用户用户名、密码以及验证码校验正确的话,服务端会返回已签名的Token,也就是JWT。

3.用户以后每次向后端发请求都在Header中带上这个JWT。

4.服务端检查JWT并从中获取用户相关信息。

两点建议:

1.建议将JWT存放在localStorage中,放在Cookie中会有CSRF风险。

2.请求服务端并携带JWT的常见做法是将其放在HTTP Header的Authorization字段中(Authorization:Bearer Token)

Part 04、 JWT如何防止被篡改? 

服务器返回签名之后,即使JWT被泄露或者截获,黑客也没办法同时篡改Signature、Header、Payload。

这是为什么呢?因为服务端拿到JWT之后,会解析出其中包含的Header、Payload 以及Signature。服务端会根据Header、Payload、密钥再次生成一个Signature。拿新生成的Signature和JWT中的Signature作对比,如果一样就说明Header和Payload没有被修改。

不过,如果服务端的秘钥也被泄露的话,黑客就可以同时篡改Signature、Header、Payload了。黑客直接修改了Header和Payload之后,再重新生成一个Signature就可以了。

❖注意:密钥一定保管好,一定不要泄露出去。JWT安全的核心在于签名,签名安全的核心在密钥。

Part 05、  JWT如何加强安全性?  

1.使用安全系数高的加密算法。

2.使用成熟的开源库,没必要造轮子。

3.JWT存放在localStorage中而不是Cookie中,避免CSRF风险。

4.一定不要将隐私信息存放在Payload当中。

5.密钥一定保管好,一定不要泄露出去。JWT安全的核心在于签名,签名安全的核心在密钥。

6.Payload要加入exp(JWT的过期时间),永久有效的JWT不合理。并且JWT的过期时间不易过长。

Part 06、  JWT有哪些优缺点?  

- 优点

1.无状态:自身携带用户信息,不需要在服务器上保存session信息。

2.可有效避免CSRF攻击:CSRF攻击需要依赖Cookie,然而JWT选择存放在localStorage中,因此非法链接无法获取JWT。 

- 缺点

1.不可控:就比如说,我们想要在JWT有效期内废弃一个JWT或者更改它的权限的话,并不会立即生效,通常需要等到有效期过后才可以。再比如说,当用户Logout的话,JWT也还有效。

Part 07、  JWT使用总结 

在“约定优于配置,配置优于编码”的开发理念下,通过Apollo配置中心,程序员不需要每次更改线上配置都要重新发布服务,成功实现了将配置与编码解耦,为线上服务变更配置提供了解决方案。


责任编辑:庞桂玉 来源: 移动Labs
相关推荐

2021-08-04 16:06:45

DataOps智领云

2022-09-22 09:00:46

CSS单位

2018-09-28 14:06:25

前端缓存后端

2022-11-06 21:14:02

数据驱动架构数据

2022-10-20 08:01:23

2023-11-27 17:35:48

ComponentWeb外层

2021-12-29 18:00:19

无损网络网络通信网络

2023-05-20 17:58:31

低代码软件

2022-07-05 06:30:54

云网络网络云原生

2022-07-26 00:00:03

语言模型人工智能

2022-12-01 17:23:45

2021-05-18 09:48:58

前端开发架构

2021-02-05 05:26:33

字节ASCII控制

2017-05-04 20:29:12

HTTP服务器TCP

2018-10-30 11:10:05

Flink数据集计算

2023-11-20 14:58:30

人工智能AI Agents

2024-01-03 08:54:17

Kubernetes策略工具

2018-09-29 04:53:37

IoT网关物联网IoT

2020-12-30 09:05:24

架构微内核系统

2022-02-22 09:33:38

LIFO数据结构
点赞
收藏

51CTO技术栈公众号