MK
摩柯社区 - 一个极简的技术知识社区
AI 面试

JWT在无状态会话中的优势

2022-02-114.4k 阅读

JWT 基础概念

JSON Web Token（JWT）是一种开放标准（RFC 7519），它定义了一种紧凑且自包含的方式，用于在各方之间以 JSON 对象的形式安全地传输信息。这些信息可以被验证和信任，因为它们是数字签名的。JWT 通常由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。

头部（Header）

头部通常由两部分组成：令牌的类型（即 JWT）和所使用的签名算法，例如 HMAC SHA256 或 RSA。以下是一个示例头部 JSON 对象：

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

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

载荷（Payload）

载荷是 JWT 的第二部分，其中包含声明（claims）。声明是关于实体（通常是用户）和其他数据的陈述。有三种类型的声明：注册声明（registered claims）、公共声明（public claims）和私有声明（private claims）。

  • 注册声明：这些是一组预定义的声明，不是强制的，但推荐使用。例如：iss（签发者）、exp（过期时间）、sub（主题）等。
  • 公共声明：可以由使用 JWT 的各方定义，但为避免冲突，应在 IANA JSON Web Token 注册表中定义，或者包含在命名空间（如 URI）中。
  • 私有声明：是为在同意使用它们的各方之间共享信息而创建的自定义声明。

以下是一个载荷示例：

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

同样，这个 JSON 对象也会被 Base64Url 编码，形成 JWT 的第二部分。

签名（Signature）

要创建签名部分，需要使用编码后的头部、编码后的载荷、一个密钥（secret）、头部中指定的签名算法。例如，如果使用 HMAC SHA256 算法，签名将按如下方式创建：

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

签名用于验证消息在传输过程中没有被更改，并且在使用私钥签名的情况下，还可以验证 JWT 的发送者的身份。

无状态会话简介

在传统的 Web 应用开发中，会话（session）管理是一个重要的部分。通常，服务器会为每个登录的用户创建一个会话，并将会话信息存储在服务器端（例如，在内存、数据库或文件系统中）。客户端通过发送包含会话标识符（如 session ID）的 cookie 或请求头来与服务器进行交互，服务器根据这个标识符来查找对应的会话信息，从而识别用户身份并维护用户状态。

然而，随着分布式系统和微服务架构的兴起，这种有状态的会话管理方式面临一些挑战：

  • 扩展性问题：在分布式环境中，会话数据需要在多个服务器实例之间共享。如果每个服务器都维护自己的会话副本，可能会导致数据不一致和同步问题。如果将会话数据集中存储在一个共享存储（如 Redis）中，又会增加系统的复杂性和单点故障的风险。
  • 负载均衡问题：负载均衡器需要确保同一用户的请求始终被路由到保存其会话数据的服务器实例上，这限制了负载均衡算法的灵活性和效率。

为了解决这些问题，无状态会话的概念应运而生。在无状态会话中，服务器不会在服务器端存储任何关于用户会话的信息。每次请求都包含足够的信息，使得服务器能够独立地处理请求，而不需要依赖之前的请求状态。这使得系统更容易扩展和实现负载均衡，因为每个请求都可以被任意服务器实例处理。

JWT 在无状态会话中的优势

1. 简洁性与紧凑性

JWT 以紧凑的 JSON 格式表示，相比传统的会话管理方式（如基于 cookie 的会话，可能需要在服务器端存储大量的会话数据），JWT 可以在客户端和服务器之间高效传输。由于 JWT 包含了验证和授权所需的所有信息，服务器无需再查询额外的存储来获取用户相关信息。例如，在一个简单的用户认证场景中，传统方式可能需要在服务器端存储用户的角色、权限等信息，而 JWT 可以将这些信息直接包含在载荷中：

{
  "sub": "user123",
  "role": "admin",
  "permissions": ["read", "write", "delete"]
}

这种紧凑性不仅减少了网络传输的数据量，还提高了系统的性能，特别是在移动设备和网络带宽有限的环境中。

2. 自包含性

JWT 的自包含特性是其在无状态会话中非常重要的优势。如前所述，JWT 包含了头部、载荷和签名，其中载荷部分携带了用户身份、权限等关键信息。这意味着服务器在接收到 JWT 后，可以独立地验证其有效性并获取所需的信息，而无需依赖任何外部存储或状态。例如，在一个微服务架构中，不同的服务可以直接验证接收到的 JWT，而不需要通过共享的会话存储来确认用户身份。 以下是一个简单的 Python Flask 应用示例，展示如何验证 JWT 并获取用户信息：

import jwt
from flask import Flask, request, jsonify

app = Flask(__name__)
SECRET_KEY = "your_secret_key"

@app.route('/protected', methods=['GET'])
def protected():
    token = request.headers.get('Authorization')
    if not token:
        return jsonify({"message": "Token is missing"}), 401
    try:
        token = token.split(' ')[1]
        data = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        return jsonify({"user": data["sub"]}), 200
    except jwt.ExpiredSignatureError:
        return jsonify({"message": "Token has expired"}), 401
    except jwt.InvalidTokenError:
        return jsonify({"message": "Invalid token"}), 401

if __name__ == '__main__':
    app.run(debug=True)

在这个示例中，Flask 应用通过验证 JWT 来保护一个受保护的路由。JWT 中的用户信息（在这个例子中是 sub 字段）可以直接从解码后的 JWT 数据中获取，而不需要查询数据库或其他会话存储。

3. 易于分布式和跨域使用

在分布式系统和微服务架构中，不同的服务可能部署在不同的服务器或容器中，甚至可能跨越不同的域。JWT 非常适合这种环境，因为它是无状态的，并且可以在不同的服务之间轻松传递。每个服务都可以独立地验证 JWT 的有效性，而不需要共享会话状态。

例如，考虑一个由用户服务、订单服务和支付服务组成的电子商务系统。用户登录后，会收到一个 JWT。当用户请求创建订单时，订单服务接收到包含 JWT 的请求，验证 JWT 后即可处理订单请求，而无需与用户服务进行额外的会话信息交互。同样，当订单需要支付时，支付服务也可以直接验证 JWT。

在跨域场景中，JWT 也很有用。传统的基于 cookie 的会话管理在跨域时会面临诸多限制，如同源策略的限制。而 JWT 可以通过请求头在不同域之间传递，不受同源策略的影响。例如，一个前端应用部署在 app.example.com，后端 API 部署在 api.example.com，前端应用可以将 JWT 放在请求头中发送给后端 API，后端 API 能够正常验证和处理请求。

4. 安全性

JWT 提供了一定的安全性保障。首先，签名机制确保了 JWT 的完整性。如果有人在传输过程中篡改了 JWT 的内容，签名验证将会失败，服务器可以拒绝该请求。其次，JWT 可以使用加密算法（如 RSA）对载荷进行加密，确保敏感信息在传输过程中不被窃取。

例如，在生成 JWT 时，可以使用 RSA 私钥进行签名：

from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import serialization, hashes
import jwt

private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048,
    backend=default_backend()
)

public_key = private_key.public_key()

private_pem = private_key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption()
)

public_pem = public_key.public_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PublicFormat.SubjectPublicKeyInfo
)

payload = {
    "sub": "user123",
    "role": "admin"
}

token = jwt.encode(
    payload,
    private_pem,
    algorithm='RS256'
)

try:
    data = jwt.decode(token, public_pem, algorithms=['RS256'])
    print(data)
except jwt.ExpiredSignatureError:
    print("Token has expired")
except jwt.InvalidTokenError:
    print("Invalid token")

在这个示例中，使用 RSA 算法生成了私钥和公钥，然后使用私钥对 JWT 进行签名。在验证 JWT 时，使用对应的公钥进行验证。这样可以防止 JWT 被篡改，并且可以通过加密载荷来保护敏感信息。

5. 易于与第三方服务集成

在现代应用开发中，经常需要与第三方服务（如社交媒体登录、支付网关等）集成。JWT 使得这种集成变得更加容易。例如，当使用社交媒体账号登录应用时，第三方认证服务可以返回一个 JWT，应用可以直接使用这个 JWT 进行后续的用户认证和授权，而不需要进行复杂的会话迁移或额外的信息同步。

假设应用使用 Google 登录，Google 认证服务器返回一个包含用户信息的 JWT。应用可以验证这个 JWT 的签名，并从中提取用户的电子邮件、姓名等信息，用于创建或更新本地用户账户。以下是一个简单的示例，展示如何使用 Python 和 google-auth 库来验证 Google 提供的 JWT：

import google.auth.transport.requests
import google.oauth2.id_token

def verify_google_jwt(token):
    request = google.auth.transport.requests.Request()
    try:
        idinfo = google.oauth2.id_token.verify_oauth2_token(token, request, "your_client_id")
        return idinfo
    except ValueError:
        return None

在这个示例中，verify_google_jwt 函数用于验证 Google 提供的 JWT。如果验证成功，将返回包含用户信息的 idinfo 对象，应用可以根据这些信息进行后续处理。

JWT 在无状态会话中的应用场景

1. Web 应用的用户认证

在 Web 应用中，JWT 可以用于用户登录认证。用户在登录时，服务器验证用户的凭据（如用户名和密码），如果验证成功，生成一个包含用户身份和权限信息的 JWT，并将其返回给客户端。客户端在后续的请求中，将 JWT 包含在请求头或 cookie 中发送给服务器。服务器接收到请求后，验证 JWT 的有效性，如果有效，则处理请求；否则，返回未授权错误。

例如，一个基于 Node.js 和 Express 的 Web 应用，实现用户登录和 JWT 认证的代码如下：

const express = require('express');
const jwt = require('jsonwebtoken');
const app = express();
const SECRET_KEY = 'your_secret_key';

// 用户登录路由
app.post('/login', (req, res) => {
    const { username, password } = req.body;
    // 假设这里验证用户名和密码
    if (username === 'valid_user' && password === 'valid_password') {
        const payload = { username };
        const token = jwt.sign(payload, SECRET_KEY, { expiresIn: '1h' });
        res.json({ token });
    } else {
        res.status(401).json({ message: 'Invalid credentials' });
    }
});

// 受保护路由
app.get('/protected', (req, res) => {
    const token = req.headers['authorization'];
    if (!token) {
        return res.status(401).json({ message: 'Token is missing' });
    }
    try {
        const decoded = jwt.verify(token.split(' ')[1], SECRET_KEY);
        res.json({ message: 'This is a protected route', user: decoded.username });
    } catch (error) {
        res.status(401).json({ message: 'Invalid token' });
    }
});

app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

在这个示例中，用户通过 /login 路由进行登录，服务器验证成功后返回一个 JWT。客户端在访问 /protected 受保护路由时，需要在请求头中包含 JWT，服务器验证 JWT 后处理请求。

2. 微服务架构中的身份验证与授权

在微服务架构中，各个微服务之间需要进行身份验证和授权。JWT 可以在微服务之间传递，每个微服务独立验证 JWT 的有效性，并根据 JWT 中的信息进行授权决策。例如，一个由用户服务、订单服务和库存服务组成的电商微服务系统。用户在登录后，会获得一个 JWT，当用户请求创建订单时，订单服务接收到包含 JWT 的请求，验证 JWT 后检查用户是否有足够的权限创建订单。如果有权限，订单服务会向库存服务发送包含 JWT 的请求，库存服务同样验证 JWT 后检查库存是否足够。

以下是一个简单的 Java Spring Boot 微服务示例，展示如何在微服务中验证 JWT：

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;
import org.springframework.web.bind.annotation.*;

import javax.crypto.SecretKey;
import java.util.Date;

@RestController
@RequestMapping("/api")
public class OrderController {
    private static final SecretKey key = Keys.secretKeyFor(SignatureAlgorithm.HS256);

    @PostMapping("/order")
    public String createOrder(@RequestHeader("Authorization") String token) {
        try {
            Claims claims = Jwts.parserBuilder()
                   .setSigningKey(key)
                   .build()
                   .parseClaimsJws(token.split(" ")[1])
                   .getBody();
            // 这里可以根据 claims 中的信息进行授权决策
            return "Order created successfully";
        } catch (Exception e) {
            return "Invalid token";
        }
    }
}

在这个示例中，OrderController 中的 createOrder 方法验证了请求头中的 JWT，并可以根据 JWT 中的 claims 信息进行授权决策。

3. 移动应用的身份验证

移动应用通常需要与后端服务器进行安全的通信。JWT 非常适合移动应用的身份验证场景，因为它的紧凑性可以减少移动设备的网络流量消耗。移动应用在用户登录后，从服务器获取 JWT，并在后续的请求中携带 JWT。例如，一个使用 Android 开发的移动应用，使用 OkHttp 库发送包含 JWT 的请求：

import okhttp3.*;
import java.io.IOException;

public class ApiClient {
    private static final String JWT_TOKEN = "your_jwt_token";
    private static final OkHttpClient client = new OkHttpClient();

    public static void main(String[] args) throws IOException {
        Request request = new Request.Builder()
               .url("https://api.example.com/protected")
               .addHeader("Authorization", "Bearer " + JWT_TOKEN)
               .build();

        try (Response response = client.newCall(request).execute()) {
            if (!response.isSuccessful()) throw new IOException("Unexpected code " + response);

            System.out.println(response.body().string());
        }
    }
}

在这个示例中，Android 应用通过 OkHttp 库发送一个包含 JWT 的请求到后端服务器的受保护 API。

JWT 的局限性

尽管 JWT 在无状态会话中有很多优势，但也存在一些局限性需要注意。

1. 令牌大小和性能

虽然 JWT 的紧凑性在大多数情况下是一个优点，但如果载荷中包含大量数据，JWT 的大小可能会显著增加。这不仅会增加网络传输的开销，还可能导致一些性能问题，特别是在移动设备和网络带宽有限的环境中。此外，每次请求都需要传输整个 JWT，这可能会浪费带宽。

2. 令牌过期和撤销

JWT 本身没有内置的机制来撤销或使令牌过期。一旦 JWT 被签发，在其过期时间（如果设置了）之前，它都是有效的。这在某些场景下可能会带来问题，例如用户注销或权限发生变化时，需要立即撤销 JWT 的有效性。一种解决方法是在服务器端维护一个已撤销的 JWT 列表，但这违背了 JWT 的无状态特性，增加了服务器的复杂性和存储需求。

3. 安全风险

尽管 JWT 提供了签名和加密机制来保证安全性，但如果密钥管理不当，仍然存在安全风险。例如，如果密钥泄露，攻击者可以伪造有效的 JWT，从而获取未授权的访问权限。此外，如果使用的签名算法或加密算法存在漏洞，也可能导致 JWT 被破解。

总结

JWT 在无状态会话中具有诸多优势，包括简洁性、自包含性、易于分布式和跨域使用、安全性以及易于与第三方服务集成等。它在 Web 应用、微服务架构和移动应用等多种场景中都有广泛的应用。然而，开发者也需要清楚地认识到 JWT 的局限性，如令牌大小和性能问题、令牌过期和撤销的挑战以及安全风险等。在实际应用中，应根据具体的需求和场景，合理地使用 JWT，并采取相应的措施来克服其局限性，以确保系统的安全和性能。通过充分发挥 JWT 的优势并妥善应对其挑战，开发者可以构建更加健壮、可扩展和安全的后端应用。