使用JWT实现单点登录

最新推荐文章于 2024-07-04 17:14:12 发布

xiaoyaGrace

最新推荐文章于 2024-07-04 17:14:12 发布

阅读量487

点赞数

分类专栏： JWT

本文链接：https://blog.csdn.net/xiaoyaGrace/article/details/104519441

版权

本文介绍了JWT（JSON Web Token）的基本概念、使用场景、结构和工作原理，并结合实际项目展示了如何使用JWT实现单点登录，包括JWT的生成、解析、校验以及客户端拦截器的配置。同时，讨论了JWT在跨域场景下的处理方法和潜在的安全问题。

摘要由CSDN通过智能技术生成

首先介绍一下什么是JSON Web Token（JWT）？
官方文档是这样解释的：JSON Web Token（JWT）是一个开放标准（RFC 7519），它定义了一种紧凑且独立的方式，可以在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。JWT可以使用秘密（使用HMAC算法）或使用RSA或ECDSA的公钥/私钥对进行签名。
虽然JWT可以加密以在各方之间提供保密，但只将专注于签名令牌。签名令牌可以验证其中包含的声明的完整性，而加密令牌则隐藏其他方的声明。当使用公钥/私钥对签署令牌时，签名还证明只有持有私钥的一方是签署私钥的一方。

通俗来讲，JWT是一个含签名并携带用户相关信息的加密串，页面请求校验登录接口时，请求头中携带JWT串到后端服务，后端通过签名加密串匹配校验，保证信息未被篡改。校验通过则认为是可靠的请求，将正常返回数据。

什么情况下使用JWT比较适合？
授权：这是最常见的使用场景，解决单点登录问题。因为JWT使用起来轻便，开销小，服务端不用记录用户状态信息（无状态），所以使用比较广泛；
信息交换：JWT是在各个服务之间安全传输信息的好方法。因为JWT可以签名，例如，使用公钥/私钥对儿 - 可以确定请求方是合法的。此外，由于使用标头和有效负载计算签名，还可以验证内容是否未被篡改。
JWT的结构体是什么样的？
JWT由三部分组成，分别是头信息、有效载荷、签名，中间以（.）分隔，如下格式：

[Java] 纯文本查看 复制代码

1	`xxx.yyy.zzz`

header（头信息）
由两部分组成，令牌类型（即：JWT）、散列算法（HMAC、RSASSA、RSASSA-PSS等），例如：

[Java] 纯文本查看 复制代码

{

"alg": "HS256",

"typ": "JWT"

}

然后，这个JSON被编码为Base64Url，形成JWT的第一部分。

Payload（有效载荷）
JWT的第二部分是payload，其中包含claims。claims是关于实体（常用的是用户信息）和其他数据的声明，claims有三种类型： registered, public, and private claims。
Registered claims：这些是一组预定义的claims，非强制性的，但是推荐使用， iss（发行人）， exp（到期时间）， sub（主题）， aud（观众）等；
Public claims: 自定义claims，注意不要和JWT注册表中属性冲突，这里可以查看JWT注册表
Private claims: 这些是自定义的claims，用于在同意使用这些claims的各方之间共享信息，它们既不是Registered claims，也不是Public claims。
以下是payload示例：

[Java] 纯文本查看 复制代码

{

"sub": "1234567890",

"name": "John Doe",

"admin": true

}

然后，再经过Base64Url编码，形成JWT的第二部分；

注意：对于签名令牌，此信息虽然可以防止篡改，但任何人都可以读取。除非加密，否则不要将敏感信息放入到Payload或Header元素中Signature
要创建签名部分，必须采用编码的Header，编码的Payload，秘钥，Header中指定的算法，并对其进行签名。
例如，如果要使用HMAC SHA256算法，将按以下方式创建签名：

[Java] 纯文本查看 复制代码

HMACSHA256(

base64UrlEncode(header) + "." +

base64UrlEncode(payload),

secret)

签名用于验证消息在此过程中未被篡改，并且，在使用私钥签名令牌的情况下，它还可以验证JWT的请求方是否是它所声明的请求方。
输出是三个由点分隔的Base64-URL字符串，可以在HTML和HTTP环境中轻松传递，与SAML等基于XML的标准相比更加紧凑。
例如：

[Java] 纯文本查看 复制代码

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT工作机制？
在身份验证中，当用户使用其凭据成功登录时，将返回JSON Web Token（即：JWT）。由于令牌是凭证，因此必须非常小心以防止出现安全问题。一般情况下，不应将令牌保留的时间超过要求。理论上超时时间越短越好。

每当用户想要访问受保护的路由或资源时，用户代理应该使用Bearer模式发送JWT，通常在Authorization header中。标题内容应如下所示：

[Java] 纯文本查看 复制代码

1	`Authorization: Bearer <token>`

在某些情况下，这可以作为无状态授权机制。服务器的受保护路由将检查Authorization header中的有效JWT ，如果有效，则允许用户访问受保护资源。如果JWT包含必要的数据，则可以减少查询数据库或缓存信息。
如果在Authorization header中发送令牌，则跨域资源共享（CORS）将不会成为问题，因为它不使用cookie。

注意：使用签名令牌，虽然他们无法更改，但是令牌中包含的所有信息都会向用户或其他方公开。这意味着不应该在令牌中放置敏感信息。

使用JWT的好处是什么？
相比Simple Web Tokens (SWT)（简单Web令牌） and Security Assertion Markup Language Tokens (SAML)（安全断言标记语言令牌）；

JWT比SAML更简洁，在HTML和HTTP环境中传递更方便；
在安全方面，SWT只能使用HMAC算法通过共享密钥对称签名。但是，JWT和SAML令牌可以使用X.509证书形式的公钥/私钥对进行签名。与签名JSON的简单性相比，使用XML数字签名可能会存在安全漏洞；
JSON解析成对象相比XML更流行、方便。
以下是我实际项目中的应用分析
首先看一下大致的架构及流程图：

主要有以下三步：

项目一开始我先封装了一个JWTHelper工具包（GitHub下载），主要提供了生成JWT、解析JWT以及校验JWT的方法，其他还有一些加密相关操作，稍后我会以代码的形式介绍下代码。工具包写好后我将打包上传到私服，能够随时依赖下载使用；
接下来，我在客户端项目中依赖JWTHelper工具包，并添加Interceptor拦截器，拦截需要校验登录的接口。拦截器中校验JWT有效性，并在response中重新设置JWT的新值；
最后在JWT服务端，依赖JWT工具包，在登录方法中，需要在登录校验成功后调用生成JWT方法，生成一个JWT令牌并且设置到response的header中。
以下是部分代码分享：

JwtHelper工具类：