Spring Boot API安全实战：RSA签名验签与防重放攻击全解析

1. 项目概述：为什么API安全不能只靠用户名密码？

做后端开发这些年，最让我头疼的不是业务逻辑有多复杂，而是接口安全问题。早期做项目，觉得在登录接口校验个用户名密码，返回个Token就万事大吉了。直到有一次，我们一个对外提供服务的支付回调接口被恶意重放攻击，同一笔支付请求被重复提交了上百次，虽然最后通过日志追查和人工对账解决了，但那个通宵排查的夜晚让我彻底明白： API安全，尤其是涉及资金和核心数据的接口，绝不能停留在“有身份认证”这个层面。

你可能会说，我们用HTTPS了，数据不是已经加密了吗？没错，HTTPS（TLS）解决了传输过程中的窃听和篡改问题，但它解决不了服务端收到请求后“这个请求到底是不是来自合法的客户端、有没有被中途掉包、是不是一个过期的请求被重新发送”这些问题。这就是我们需要在应用层再筑一道防线的原因。

而 签名验签 ，就是这道防线的核心。它就像古代调兵遣将的虎符，客户端和服务端各持一半，只有严丝合缝地对上，命令才被认可。在这个项目里，我们选择用 RSA非对称加密算法 来实现这套机制。为什么是RSA而不是MD5、SHA256这些哈希算法？因为单纯的哈希（比如MD5加盐）是对称的，双方需要共享同一个密钥（盐），一旦密钥泄露，整个安全体系就崩塌了。RSA的公钥私钥分离特性，完美解决了密钥分发和保管的难题：客户端用私钥签名，服务端用公开的公钥验签，私钥永远不用在网络中传输。

所以，这个“从登录到支付”的项目，目标很明确：在Spring Boot构建的API体系中，从用户登录开始，到最终的支付下单，每一个关键接口的请求，都要经过RSA签名的保护。让任何试图伪造、重放、篡改请求的行为都无所遁形。接下来，我就把手把手带你，从原理到代码，把这套机制搭建起来。

2. 核心原理拆解：RSA签名验签如何充当“数字指纹”

在写代码之前，我们必须把原理吃透。很多人知道RSA能加密解密，但对签名验签却一知半解，其实它的逻辑非常直观。

2.1 签名：生成不可伪造的“数字指纹”

想象一下，你要寄一封重要的挂号信。签名过程就相当于你在写完信后，用一个只有你有的特殊印章（私钥）在信封的封口处盖了个戳。这个戳的图案是独一无二的，且与信的具体内容（原文）有关。如果有人拆开信改了内容，他就无法复原你原来的那个戳；如果他试图伪造一个你的戳，因为没有你的印章，他也做不到。

技术流程是这样的：

1. 获取原文摘要 ：首先，客户端需要对要发送的请求数据（比如 {"orderId":"123", "amount":100} ）计算一个哈希值（如SHA256）。这个过程叫做“摘要”。摘要有两个特点：一是无论原文多长，摘要长度固定；二是原文哪怕只改一个标点，摘要都会天差地别。这相当于把一封信压缩成一个唯一的“内容指纹”。
2. 私钥加密摘要 ：然后，客户端用自己的 RSA私钥 对这个“内容指纹”进行加密。加密后的结果，就是 数字签名 。这个签名是绑定这份特定请求数据的。
3. 发送 ：最后，客户端将 原始请求数据 和 数字签名 一起发送给服务端。注意，原始数据本身不加密（除非有额外加密需求），我们保护的是它的完整性和不可否认性。

关键理解 ：签名并不是加密整个请求报文，那样性能开销太大。它只加密一个固定长度的摘要，效率极高。私钥始终牢牢掌握在客户端手中（对于服务器间调用，客户端就是调用方服务器），绝不外泄。

2.2 验签：核对“指纹”与“印章”

服务端收到信件后，需要验证这个封口的戳是不是真的，信的内容有没有被调包。

1. 重新计算摘要 ：服务端拿到客户端发来的 原始请求数据 ，使用同样的哈希算法（比如SHA256）重新计算一次摘要，得到“摘要A”。
2. 公钥解密签名 ：服务端用事先持有的、与客户端私钥配对的 RSA公钥 ，去解密客户端附送过来的 数字签名 。解密成功，会得到一串数据，我们称之为“摘要B”。如果解密失败，说明签名格式不对或者根本不是用对应私钥签的，直接验签失败。
3. 比对摘要 ：最后，比较服务端自己算出来的“摘要A”和从签名里解密出来的“摘要B”。如果两者完全一致，恭喜，验签通过！这意味着：第一，这份数据确实是由持有对应私钥的客户端发送的（身份认证）；第二，数据在传输过程中没有被篡改（完整性）。

2.3 为什么能防重放？

单纯的签名验签还不能防重放。一个合法的签名请求被攻击者截获后，他完全可以原封不动地再发给服务器一次。为了解决这个问题，我们必须在签名原料里加入“一次性”或“时效性”要素。

• 方案一：时间戳（Timestamp） ：客户端在签名时，将当前时间戳（如 timestamp=1625097600000 ）也作为原始数据的一部分进行签名。服务端验签时，除了校验签名本身，还会检查这个时间戳与服务器当前时间是否在允许的误差范围内（例如±5分钟）。超过这个范围的请求，视为重放攻击，直接拒绝。
• 方案二：随机数（Nonce） ：客户端每次请求生成一个全局唯一的随机字符串（Nonce），并和签名一起发送。服务端维护一个短期缓存（如最近5分钟），检查这个Nonce是否已经被使用过。如果用过，则拒绝。这个方案更彻底，但需要服务端有存储和查重能力。

在实际项目中，我推荐 时间戳+Nonce 结合的方式，既保证了时效性，又通过一次性的Nonce杜绝了在时间窗口内的重放，安全性最高。我们后续的实战也会采用这种方式。

3. 实战环境搭建与核心工具类编写

理论清楚了，我们开始动手。首先创建一个标准的Spring Boot项目，这里我选择常用的2.7.x版本，JDK 11。

3.1 生成RSA密钥对

一切的基础是密钥对。我们可以在线生成，也可以用Java代码生成。为了演示完整流程，我们写一个简单的工具类来生成并保存密钥对。在实际生产环境中，私钥应由客户端安全保管（如存放在硬件加密模块、配置中心或受严格权限控制的文件中），公钥则分发给所有需要验签的服务端。

import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.PrivateKey;
import java.security.PublicKey;
import java.util.Base64;

public class RSAKeyGenerator {
    public static void main(String[] args) throws Exception {
        // 1. 获取RSA密钥对生成器实例
        KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");
        // 2. 初始化密钥长度。2048位是当前安全的最低要求，推荐使用3072或4096位以应对未来算力提升。
        keyPairGen.initialize(2048);
        // 3. 生成密钥对
        KeyPair keyPair = keyPairGen.generateKeyPair();
        PrivateKey privateKey = keyPair.getPrivate();
        PublicKey publicKey = keyPair.getPublic();

        // 4. 获取Base64编码的字符串格式，方便存储和配置
        String privateKeyStr = Base64.getEncoder().encodeToString(privateKey.getEncoded());
        String publicKeyStr = Base64.getEncoder().encodeToString(publicKey.getEncoded());

        System.out.println("=========== 私钥 (Private Key) ===========");
        System.out.println("请妥善保管，切勿泄露！");
        System.out.println(privateKeyStr);
        System.out.println("\n=========== 公钥 (Public Key) ===========");
        System.out.println("可配置在服务端应用配置文件中。");
        System.out.println(publicKeyStr);
    }
}

运行这段代码，你会得到两串很长的Base64字符串，分别就是私钥和公钥。把它们存下来，我们后面要用。

实操心得一：密钥长度与格式 密钥长度直接关系到安全性。1024位的RSA现在已不安全， 绝对不要用 。2048位是目前线上系统的基线。对于金融、支付等敏感系统，建议直接使用3072或4096位。生成的密钥通常是PKCS#8格式的，Spring Security或 java.security 包都能直接处理这种Base64编码的字符串。如果遇到其他格式（如PKCS#1，通常以 -----BEGIN RSA PRIVATE KEY----- 开头），可能需要先用 openssl 等工具进行转换。

3.2 编写签名与验签工具类

接下来，我们编写一个通用的 RSAUtils 工具类，封装签名和验签的逻辑。

import lombok.extern.slf4j.Slf4j;
import org.apache.commons.codec.binary.Base64;

import javax.crypto.Cipher;
import java.nio.charset.StandardCharsets;
import java.security.*;
import java.security.spec.PKCS8EncodedKeySpec;
import java.security.spec.X509EncodedKeySpec;

@Slf4j
public class RSAUtils {

    private static final String RSA_ALGORITHM = "RSA";
    private static final String SIGN_ALGORITHM = "SHA256withRSA";

    /**
     * 从Base64字符串加载私钥
     */
    public static PrivateKey loadPrivateKey(String privateKeyStr) throws Exception {
        byte[] keyBytes = Base64.decodeBase64(privateKeyStr);
        PKCS8EncodedKeySpec keySpec = new PKCS8EncodedKeySpec(keyBytes);
        KeyFactory keyFactory = KeyFactory.getInstance(RSA_ALGORITHM);
        return keyFactory.generatePrivate(keySpec);
    }

    /**
     * 从Base64字符串加载公钥
     */
    public static PublicKey loadPublicKey(String publicKeyStr) throws Exception {
        byte[] keyBytes = Base64.decodeBase64(publicKeyStr);
        X509EncodedKeySpec keySpec = new X509EncodedKeySpec(keyBytes);
        KeyFactory keyFactory = KeyFactory.getInstance(RSA_ALGORITHM);
        return keyFactory.generatePublic(keySpec);
    }

    /**
     * 使用私钥对数据进行签名
     * @param data 待签名的原始字符串（通常是排序后的参数拼接串）
     * @param privateKey 私钥
     * @return Base64编码的签名结果
     */
    public static String sign(String data, PrivateKey privateKey) throws Exception {
        Signature signature = Signature.getInstance(SIGN_ALGORITHM);
        signature.initSign(privateKey);
        signature.update(data.getBytes(StandardCharsets.UTF_8));
        byte[] signBytes = signature.sign();
        return Base64.encodeBase64String(signBytes);
    }

    /**
     * 使用公钥验证签名
     * @param data 待验证的原始字符串
     * @param sign Base64编码的签名字符串
     * @param publicKey 公钥
     * @return 验签是否通过
     */
    public static boolean verify(String data, String sign, PublicKey publicKey) throws Exception {
        Signature signature = Signature.getInstance(SIGN_ALGORITHM);
        signature.initVerify(publicKey);
        signature.update(data.getBytes(StandardCharsets.UTF_8));
        return signature.verify(Base64.decodeBase64(sign));
    }
}

这个工具类提供了密钥加载、签名和验签的基础方法。注意 SIGN_ALGORITHM 我们选择了 SHA256withRSA ，这表示先用SHA256算法做摘要，再用RSA私钥加密。这是目前最主流、最安全的搭配。

4. 集成Spring Boot：设计全局签名过滤器与防重放机制

现在，我们要把签名验签逻辑无缝集成到Spring Boot的Web请求生命周期中。最佳实践是使用一个 过滤器（Filter） 或 拦截器（Interceptor） ，在请求进入Controller之前统一完成验签。这里我选择过滤器，因为它更底层，能处理所有类型的请求。

4.1 构建可验签的请求体

首先，我们需要定义客户端应该如何组织请求。一个标准的、带签名和防重放的HTTP请求（以POST JSON为例）应该包含以下部分：

• 请求头（Headers） :
  • X-App-Id : 客户端应用标识，用于区分不同的调用方。
  • X-Nonce : 唯一随机字符串，用于防重放。
  • X-Timestamp : 当前时间戳（毫秒）。
  • X-Signature : RSA签名结果（Base64编码）。
• 请求体（Body） : 实际的业务JSON数据。

客户端签名的步骤：

1. 将业务参数（JSON Body）按固定规则（如按Key字母序排序）拼接成字符串 bodyStr 。
2. 将 X-App-Id 、 X-Nonce 、 X-Timestamp 和 bodyStr 按预定顺序（例如 appId+nonce+timestamp+bodyStr ）拼接成一个待签名字符串 signString 。
3. 使用自己的私钥，通过 RSAUtils.sign(signString, privateKey) 生成签名。
4. 将签名放入 X-Signature 头，连同其他头和Body发送请求。

4.2 实现全局签名验证过滤器

我们在服务端实现一个过滤器来拦截并验证这些信息。

import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.Data;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;
import org.springframework.util.StreamUtils;

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.security.PublicKey;
import java.util.concurrent.TimeUnit;

@Component
@Order(1) // 确保过滤器在Spring Security等过滤器之前执行
@Slf4j
public class SignatureAuthFilter implements Filter {

    @Value("${rsa.public-key}")
    private String publicKeyStr; // 从配置文件中读取公钥

    @Value("${signature.timeout:300000}") // 默认5分钟超时
    private long timeoutMillis;

    private PublicKey publicKey;
    private final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        try {
            // 初始化时加载公钥
            this.publicKey = RSAUtils.loadPublicKey(publicKeyStr);
            log.info("RSA验签过滤器初始化成功，公钥已加载。");
        } catch (Exception e) {
            log.error("初始化RSA公钥失败！", e);
            throw new ServletException("Failed to init RSA public key", e);
        }
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        // 1. 获取必要的请求头
        String appId = httpRequest.getHeader("X-App-Id");
        String nonce = httpRequest.getHeader("X-Nonce");
        String timestampStr = httpRequest.getHeader("X-Timestamp");
        String signature = httpRequest.getHeader("X-Signature");

        // 2. 基础校验：检查必要请求头是否存在
        if (appId == null || nonce == null || timestampStr == null || signature == null) {
            sendErrorResponse(httpResponse, 400, "Missing required headers (X-App-Id, X-Nonce, X-Timestamp, X-Signature)");
            return;
        }

        // 3. 防重放校验：检查时间戳
        long timestamp;
        try {
            timestamp = Long.parseLong(timestampStr);
        } catch (NumberFormatException e) {
            sendErrorResponse(httpResponse, 400, "Invalid timestamp format");
            return;
        }
        long currentTime = System.currentTimeMillis();
        if (Math.abs(currentTime - timestamp) > timeoutMillis) {
            sendErrorResponse(httpResponse, 400, "Request expired or timestamp invalid");
            return;
        }

        // 4. 防重放校验：检查Nonce（这里简化演示，使用内存缓存。生产环境应用Redis等分布式缓存）
        // String cacheKey = "nonce:" + appId + ":" + nonce;
        // if (nonceCache.exists(cacheKey)) {
        //     sendErrorResponse(httpResponse, 400, "Duplicate request (Nonce used)");
        //     return;
        // } else {
        //     nonceCache.set(cacheKey, "1", 5, TimeUnit.MINUTES); // 缓存5分钟
        // }

        // 5. 读取请求体（注意：HttpServletRequest的输入流只能读一次，需要包装）
        String requestBody;
        try {
            requestBody = StreamUtils.copyToString(httpRequest.getInputStream(), StandardCharsets.UTF_8);
        } catch (IOException e) {
            sendErrorResponse(httpResponse, 400, "Failed to read request body");
            return;
        }

        // 6. 构建待签名字符串（规则必须与客户端严格一致）
        String signString = buildSignString(appId, nonce, timestampStr, requestBody);
        log.debug("待验签字符串: {}", signString);

        // 7. 执行RSA验签
        boolean verifyResult;
        try {
            verifyResult = RSAUtils.verify(signString, signature, publicKey);
        } catch (Exception e) {
            log.error("验签过程发生异常", e);
            sendErrorResponse(httpResponse, 500, "Signature verification error");
            return;
        }

        if (!verifyResult) {
            sendErrorResponse(httpResponse, 401, "Invalid signature");
            return;
        }

        // 8. 验签通过，将请求体等信息放入请求属性，供后续使用，并放行请求
        // 由于输入流已读取，需要重新包装请求对象，这里简单将body存入属性
        request.setAttribute("verifiedBody", requestBody);
        request.setAttribute("appId", appId);
        chain.doFilter(request, response);
    }

    private String buildSignString(String appId, String nonce, String timestamp, String body) {
        // 按约定规则拼接，例如：appId + "&" + nonce + "&" + timestamp + "&" + body
        // 注意：如果body为空，也需要保持一致的处理逻辑（如用空字符串""）
        return String.join("&", appId, nonce, timestamp, body);
    }

    private void sendErrorResponse(HttpServletResponse response, int status, String message) throws IOException {
        response.setStatus(status);
        response.setContentType("application/json;charset=UTF-8");
        ErrorResult errorResult = new ErrorResult(status, message);
        response.getWriter().write(objectMapper.writeValueAsString(errorResult));
    }

    @Data
    private static class ErrorResult {
        private int code;
        private String msg;
        public ErrorResult(int code, String msg) {
            this.code = code;
            this.msg = msg;
        }
    }
}

这个过滤器做了以下几件关键事情：

1. 读取并校验请求头 ：确保必要的签名元数据都存在。
2. 时间戳校验 ：拒绝过期或时间偏差过大的请求。
3. Nonce校验（注释中） ：防止同一请求在有效期内被重复提交。生产环境务必实现，可以用Redis存储已使用的Nonce，并设置合理的过期时间（略大于时间戳允许的误差窗口）。
4. 构建签名字符串 ：按照与客户端约定的 完全相同 的规则拼接字符串。 这是最容易出错的环节，客户端和服务端的拼接规则必须一字不差。
5. 执行验签 ：调用我们的 RSAUtils.verify 方法进行验证。
6. 请求放行或拦截 ：验签成功，将请求信息放入属性并放行；失败则返回明确的错误信息。

实操心得二：请求体的读取与缓存 HttpServletRequest 的 InputStream 只能读取一次。在过滤器中读取了请求体后，后续的Controller就无法再读取了。上面的示例将读取到的body字符串存入请求属性 verifiedBody 。更优雅的做法是使用 ContentCachingRequestWrapper （Spring提供）或自定义 HttpServletRequestWrapper 来包装请求，实现对请求体的缓存和多次读取。这是集成时需要特别注意的一个坑。

5. 客户端签名SDK与完整调用示例

服务端准备好了，我们再来看看客户端该如何调用。一个好的实践是将签名逻辑封装成一个轻量级的SDK或者一个 RestTemplate 的拦截器，让业务代码无需关心签名细节。

5.1 封装一个签名HTTP客户端工具

这里以使用Spring的 RestTemplate 为例，通过自定义 ClientHttpRequestInterceptor 在请求发出前自动完成签名。

import lombok.extern.slf4j.Slf4j;
import org.springframework.http.HttpRequest;
import org.springframework.http.client.ClientHttpRequestExecution;
import org.springframework.http.client.ClientHttpRequestInterceptor;
import org.springframework.http.client.ClientHttpResponse;
import org.springframework.stereotype.Component;

import java.io.IOException;
import java.security.PrivateKey;
import java.util.UUID;

@Slf4j
@Component
public class SignatureInterceptor implements ClientHttpRequestInterceptor {

    private final String appId;
    private final PrivateKey privateKey;

    // 通过构造器注入应用标识和私钥（私钥应从安全的地方获取，如配置中心、密钥管理系统）
    public SignatureInterceptor(@Value("${client.app-id}") String appId,
                                @Value("${client.private-key}") String privateKeyStr) throws Exception {
        this.appId = appId;
        this.privateKey = RSAUtils.loadPrivateKey(privateKeyStr);
    }

    @Override
    public ClientHttpResponse intercept(HttpRequest request, byte[] body, ClientHttpRequestExecution execution) throws IOException {
        // 1. 生成防重放参数
        String nonce = UUID.randomUUID().toString().replace("-", "");
        String timestamp = String.valueOf(System.currentTimeMillis());

        // 2. 获取请求体内容（byte[] 转 String）
        String bodyStr = new String(body, StandardCharsets.UTF_8);

        // 3. 构建待签名字符串（规则必须与服务端严格一致！）
        String signString = buildSignString(appId, nonce, timestamp, bodyStr);

        // 4. 生成签名
        String signature;
        try {
            signature = RSAUtils.sign(signString, privateKey);
        } catch (Exception e) {
            log.error("生成签名失败", e);
            throw new RuntimeException("Failed to generate signature", e);
        }

        // 5. 将签名和元数据放入请求头
        request.getHeaders().add("X-App-Id", appId);
        request.getHeaders().add("X-Nonce", nonce);
        request.getHeaders().add("X-Timestamp", timestamp);
        request.getHeaders().add("X-Signature", signature);
        // 通常也需要设置Content-Type
        request.getHeaders().add("Content-Type", "application/json;charset=UTF-8");

        log.debug("请求已签名，nonce:{}, timestamp:{}", nonce, timestamp);
        // 6. 继续执行请求
        return execution.execute(request, body);
    }

    private String buildSignString(String appId, String nonce, String timestamp, String body) {
        // 必须与服务端过滤器中的buildSignString逻辑完全一致！
        return String.join("&", appId, nonce, timestamp, body);
    }
}

然后，在配置类中将这个拦截器注入到 RestTemplate 中：

@Configuration
public class RestTemplateConfig {
    @Bean
    public RestTemplate restTemplate(SignatureInterceptor signatureInterceptor) {
        RestTemplate restTemplate = new RestTemplate();
        // 添加签名拦截器
        restTemplate.getInterceptors().add(signatureInterceptor);
        // 可以添加其他拦截器，如日志拦截器
        return restTemplate;
    }
}

这样，在业务代码中，你只需要像平常一样使用 RestTemplate 发起HTTP调用，所有的签名、加头操作都会自动完成。

@Service
public class PaymentService {
    @Autowired
    private RestTemplate restTemplate;

    public void createRemoteOrder(OrderDTO orderDTO) {
        String url = "https://api.your-payment.com/v1/order/create";
        // 直接发起请求，签名拦截器已在背后工作
        ResponseEntity<String> response = restTemplate.postForEntity(url, orderDTO, String.class);
        // ... 处理响应
    }
}

5.2 从登录到支付的完整流程串联

现在，让我们把“登录”和“支付”两个场景串联起来，看看签名验签如何贯穿始终。

场景一：用户登录

1. 客户端（App/前端）收集用户名、密码。
2. 客户端使用自身的私钥，对包含登录信息、Nonce、时间戳的字符串进行签名。
3. 客户端将签名、登录请求体、Nonce、时间戳、AppID一起发送到服务端的登录接口。
4. 服务端的 SignatureAuthFilter 拦截请求，进行验签、防重放检查。
5. 验签通过后，请求到达 LoginController ，进行密码校验等业务逻辑。
6. 登录成功，服务端生成一个会话Token（如JWT）返回给客户端。 注意：这个Token用于后续的会话身份管理，与API签名是两套并行的安全机制。签名保证请求来源可信且未被篡改，Token保证用户身份持续有效。

场景二：发起支付

1. 用户在客户端确认订单，点击支付。
2. 客户端构造支付请求（包含订单号、金额、支付方式等）。
3. 客户端使用同样的私钥，对支付请求进行签名（同样包含Nonce、时间戳）。
4. 客户端将签名后的支付请求发送到服务端的支付接口。
5. 服务端的 SignatureAuthFilter 再次验签。同时，支付接口本身可能还需要通过 @PreAuthorize 等注解校验JWT Token中的用户权限。
6. 验签和授权均通过后，执行创建支付订单、调用支付渠道等核心业务逻辑。

可以看到， 签名验签作为第一道网关，守护着每一个关键的业务入口 。而用户身份的认证与授权（如JWT）则在其后或并行工作，两者各司其职，共同构建了纵深防御体系。

6. 生产环境进阶考量与避坑指南

把Demo跑起来只是第一步，要真正上线，还有一大堆细节和坑需要填平。下面是我从实际项目中总结出来的经验。

6.1 密钥管理：安全是生命线

私钥泄露意味着攻击者可以伪造任何合法请求。管理好密钥比算法本身更重要。

• 绝对不要硬编码 ：严禁将私钥以明文形式写在代码或配置文件中提交到代码仓库。
• 推荐方案 ：
  • 硬件安全模块（HSM）/密钥管理服务（KMS） ：如阿里云KMS、AWS KMS、HashiCorp Vault。客户端通过API动态获取签名密钥或直接调用签名服务。这是安全等级最高的方案。
  • 配置中心 ：将加密后的私钥存放在Apollo、Nacos等配置中心，应用启动时拉取并解密。解密密钥可以通过环境变量或启动参数传入。
  • 文件系统 ：将私钥文件放在服务器特定目录，通过严格的文件权限（如600）控制访问。这比放在代码里好，但仍有服务器被入侵后泄露的风险。
• 密钥轮转 ：定期（如每季度或每年）更换密钥对。需要设计平滑的过渡方案，比如新旧公钥同时在服务端并存一段时间，客户端逐步升级。

6.2 签名算法与性能优化

• 算法选择 ： SHA256withRSA 是黄金标准。 SHA1withRSA 已不安全，禁止使用。对于性能极端敏感且安全性要求稍低的内部系统，可以考虑 SHA256withECDSA （ECDSA），在相同安全强度下，签名速度更快，密钥更短。
• 性能瓶颈 ：RSA签名验签是CPU密集型操作。在高并发场景下，可能成为瓶颈。
  • 优化验签 ：验签（公钥操作）比签名（私钥操作）快很多。压力主要在服务端。可以考虑：
    • 对验签通过的请求，将其 AppID+Nonce+Timestamp+签名 的组合结果缓存起来（缓存几分钟）。在时间窗口内收到完全相同的请求，可以直接命中缓存通过，避免重复的验签计算。 但要极其注意缓存键的设计，必须包含所有可变因素，防止绕过。
    • 对于 GET 等幂等查询请求，可以考虑根据业务安全性要求，在特定路径上关闭验签，或使用更轻量的HMAC-SHA256（但需解决密钥分发问题）。
• 请求体过大 ：如果请求体是几MB的大JSON，每次都全量参与签名计算和传输会影响性能。可以考虑对请求体单独计算一个SHA256摘要，然后将这个摘要作为参数之一参与签名。服务端收到后，同样计算请求体摘要进行比对。这样待签名字符串的长度就固定了。

6.3 常见问题排查实录

在实际运维中，签名验签失败是高频问题。下面是一个快速排查清单：

6.4 监控与审计

上线后，监控必不可少。

• 日志记录 ：在过滤器中，详细记录验签成功/失败的日志，包括AppID、请求IP、URL、时间戳、Nonce。失败日志尤其重要，是发现攻击行为的关键。
• ** metrics监控**：统计验签的QPS、成功率、平均耗时。设置告警，当验签失败率突然飙升时，可能正在遭受攻击或客户端有bug。
• 审计跟踪 ：对于支付、资金变动等核心操作，应将完整的请求（包括签名、头、体）和验签结果落盘到安全的审计日志中，供事后追溯。

7. 总结与个人体会

走完这一整套流程，从生成密钥对到编写工具类，再到集成过滤器和实现客户端SDK，最后考虑生产环境的种种细节，你会发现，为Spring Boot API加上RSA签名验签这套铠甲，其实是一个系统工程，而不仅仅是几行加密代码。

我个人最大的体会是： 安全是一个“契约” 。签名验签的成败，90%取决于客户端和服务端是否严格遵守了同一套“契约”——相同的拼接规则、相同的编码、相同的算法、同步的时间。在联调阶段，花费时间最多的地方往往就是两边在核对这个“契约”的细节。建立一个清晰的、文档化的签名规范，并在双方团队内达成共识，比技术实现本身更重要。

另外， 没有银弹 。RSA签名验签解决了请求来源可信和防篡改的问题，但它不加密数据，不防泄漏，也不能替代HTTPS、权限校验、输入验证、SQL注入防护等其他安全措施。它应该被作为你API安全防御矩阵中坚实的一环，与其他安全实践协同工作。

最后，关于性能的担忧，我的经验是，对于绝大多数业务系统，RSA2048的验签开销是完全可以接受的。在网关层或过滤层统一处理，配合适当的缓存策略，其带来的安全性提升远超过那一点CPU消耗。当你的接口开始处理真金白银时，你就会明白，这份“重量”是值得的。