JWT

本文翻译自JWT官方网站对JWT是什么以及能做什么的简介。

JWT是一种用于双方之间传递安全信息的简洁的、URL安全的表述性声明规范。JWT作为一个开放的标准( RFC 7519 ),定义了一种简洁的,自包含的方法用于通信双方之间以Json对象的形式安全的传递信息。因为数字签名的存在,这些信息是可信的,JWT可以使用HMAC算法或者是RSA的公私秘钥对进行签名。

  • 简洁(Compact): 可以通过URL,POST参数或者在HTTP header发送,因为数据量小,传输速度也很快

  • 自包含(Self-contained):负载中包含了所有用户所需要的信息,避免了多次查询数据库

JWT的主要应用场景

  • 身份认证

    
    在这种场景下,一旦用户完成了登陆,在接下来的每个请求中包含JWT,可以用来验证用户身份以及对路由,服务和资源的访问权限进行验证。由于它的开销非常小,可以轻松的在不同域名的系统中传递,所有目前在单点登录(SSO)中比较广泛的使用了该技术。
    
  • 信息交换

    在通信的双方之间使用JWT对数据进行编码是一种非常安全的方式,由于它的信息是经过签名的,可以确保发送者发送的信息是没有经过伪造的。
    

JWT的结构

JWT包含了使用 . 分隔的三部分:

  • Header 头部

  • Payload 负载

  • Signature 签名

其结构看起来是这样的

xxxxx.yyyyy.zzzzz

Header

在header中通常包含了两部分:token类型和采用的加密算法。

{
  "alg": "HS256",
  "typ": "JWT"
}  

接下来对这部分内容使用 Base64Url 编码组成了JWT结构的第一部分。

Payload

Token的第二部分是负载,它包含了claim, Claim是一些实体(通常指的用户)的状态和额外的元数据,有三种类型的claim: reserved , public 和 private .

  • Reserved claims: 这些claim是JWT预先定义的,在JWT中并不会强制使用它们,而是推荐使用,常用的有 iss(签发者) , exp(过期时间戳) , sub(面向的用户) , aud(接收方) , iat(签发时间) 。

  • Public claims:根据需要定义自己的字段,注意应该避免冲突

  • Private claims:这些是自定义的字段,可以用来在双方之间交换信息

负载使用的例子:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

上述的负载需要经过 Base64Url 编码后作为JWT结构的第二部分。

Signature

创建签名需要使用编码后的header和payload以及一个秘钥,使用header中指定签名算法进行签名。例如如果希望使用HMAC SHA256算法,那么签名应该使用下列方式创建:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)  

签名用于验证消息的发送者以及消息是没有经过篡改的。

完整的JWT

JWT格式的输出是以 . 分隔的三段Base64编码,与SAML等基于XML的标准相比,JWT在HTTP和HTML环境中更容易传递。

下列的JWT展示了一个完整的JWT格式,它拼接了之前的Header, Payload以及秘钥签名:

如何使用JWT?

在身份鉴定的实现中,传统方法是在服务端存储一个session,给客户端返回一个cookie,而使用JWT之后,当用户使用它的认证信息登陆系统之后,会返回给用户一个JWT,用户只需要本地保存该token(通常使用local storage,也可以使用cookie)即可。

当用户希望访问一个受保护的路由或者资源的时候,通常应该在 Authorization 头部使用 Bearer 模式添加JWT,其内容看起来是下面这样:

Authorization: Bearer <token>

因为用户的状态在服务端的内存中是不存储的,所以这是一种 无状态 的认证机制。服务端的保护路由将会检查请求头 Authorization 中的JWT信息,如果合法,则允许用户的行为。由于JWT是自包含的,因此减少了需要查询数据库的需要。

JWT的这些特性使得我们可以完全依赖其无状态的特性提供数据API服务,甚至是创建一个下载流服务。因为JWT并不使用Cookie的,所以你可以使用任何域名提供你的API服务而不需要担心跨域资源共享问题(CORS)。

下面的序列图展示了该过程:

为什么要使用JWT?

相比XML格式,JSON更加简洁,编码之后更小,这使得JWT比SAML更加简洁,更加适合在HTML和HTTP环境中传递。

在安全性方面,SWT只能够使用HMAC算法和共享的对称秘钥进行签名,而JWT和SAML token则可以使用X.509认证的公私秘钥对进行签名。与简单的JSON相比,XML和XML数字签名会引入复杂的安全漏洞。

因为JSON可以直接映射为对象,在大多数编程语言中都提供了JSON解析器,而XML则没有这么自然的文档-对象映射关系,这就使得使用JWT比SAML更方便。

原文: Introduction to JSON Web Tokens

JWT(JSON Web Token)是一个开放标准(RFC 7519),它定义了一种紧凑的、自包含的方式,用于作为JSON对象在各方之间安全地传输信息,且该信息因数字签名而可被验证和信任[^1][^2][^4]。 ### 原理 服务器端初次验明用户身份后,会生成带有签名的 Json 对象并返回给客户端,客户端存储该对象。后续请求时,客户端将其与请求一并发送至服务器,服务器通过这个 Json 对象标识用户[^3]。 ### 使用方法 1. **生成 JWT**:服务器在用户认证成功后,依据特定算法(如 HMAC、RSA/ECDSA)对包含用户信息(如用户 ID、角色等)的 JSON 对象进行签名,生成 JWT。示例代码(Python,使用 PyJWT 库): ```python import jwt from datetime import datetime, timedelta # 密钥 SECRET_KEY = "your_secret_key" # 要包含在 JWT 中的信息 payload = { "user_id": 1, "role": "admin", "exp": datetime.utcnow() + timedelta(hours=1) # 设置过期时间 } # 生成 JWT token = jwt.encode(payload, SECRET_KEY, algorithm="HS256") print(token) ``` 2. **验证 JWT**:服务器接收到客户端请求中的 JWT 后,使用相同的密钥和算法对其进行验证,若验证通过则确认用户身份。示例代码: ```python try: # 验证 JWT decoded = jwt.decode(token, SECRET_KEY, algorithms=["HS256"]) print(decoded) except jwt.ExpiredSignatureError: print("Token 已过期") except jwt.InvalidTokenError: print("无效的 Token") ``` ### 应用场景 1. **跨域身份验证**:是目前最流行的跨域身份验证解决方案,由于其紧凑格式,可通过 URL、POST 参数或 HTTP 头发送,能轻松在多个域之间传递和使用,实现跨域授权[^1]。 2. **微服务架构**:在微服务架构里,很多服务独立部署且可横向扩展,需保证认证和授权的无状态性。使用 JWT 可满足此需求,每次请求携带 JWT 即可实现认证和授权[^5]。 3. **前后端分离项目**:服务器端生成 JWT 给前端,前端在后续请求中携带该 JWT,服务器通过验证 JWT 来确认用户身份,减少服务器存储状态的负担。 ### 优势 1. **无需服务器存储状态**:传统基于会话的认证机制需服务器在会话中存储用户状态信息,而 JWT 所有认证和授权信息都包含在内,便于系统水平扩展[^5]。 2. **自包含**:包含认证和授权信息及其他自定义声明,编码在 JWT 中,服务端解码后使用,减少对服务端资源依赖,提供统一安全机制[^5]。 3. **扩展性**:可扩展和定制,能按需添加自定义声明和数据,灵活性高[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值