本文还有配套的精品资源，点击获取

简介：在Java Web开发中，保障接口安全至关重要。本文围绕Token验证和基于注解的权限管理两大核心安全机制展开，详细介绍了如何通过JWT和OAuth2实现无状态身份认证，并利用Spring Security的 @Secured 、 @PreAuthorize 等注解灵活控制接口访问权限。配套代码示例涵盖Token解析、签名验证、过期处理及安全配置类，帮助开发者快速集成安全功能，提升系统安全性。

1. Java Web安全机制概述

在现代Web应用开发中，安全性是系统设计的重要组成部分。Java Web应用通常面临诸如身份伪造、越权访问、会话劫持等安全威胁，因此构建一套健全的安全机制至关重要。Java Web安全主要包括身份认证（Authentication）、授权（Authorization）和会话管理（Session Management）三大核心模块。其中，Token机制作为无状态认证的关键技术，在分布式和微服务架构中扮演着越来越重要的角色。本章将帮助读者建立对Java Web安全的整体认知框架，为后续深入理解Token验证、JWT结构、OAuth2流程及Spring Security注解权限控制等内容奠定坚实的理论基础。

2. Token验证原理与流程

在现代Java Web应用的安全体系中，Token机制作为无状态认证的核心技术，广泛应用于分布式系统、微服务架构以及前后端分离的项目中。与传统的Session机制相比，Token提供了更灵活、更安全的认证方式，尤其适合高并发、跨域、移动端等复杂网络环境下。本章将从Token的基本原理出发，深入解析其验证流程与安全机制，为后续的JWT和OAuth2实践打下坚实基础。

2.1 Token的基本概念与应用场景

Token（令牌）是一种用于身份认证和授权的轻量级凭证，通常由服务端生成并返回给客户端，客户端在后续请求中携带该Token以完成身份识别和权限判断。Token机制广泛应用于现代Web系统中，尤其是在RESTful API、移动端应用、单点登录（SSO）等场景中，其无状态特性极大提升了系统的可扩展性与安全性。

2.1.1 Token与Session的区别

对比维度	Session机制	Token机制
存储方式	服务端存储用户状态信息	客户端携带Token信息
状态管理	有状态（需服务端维护会话）	无状态（每次请求携带完整凭证）
可扩展性	随着用户量增加，存储压力增大	易于横向扩展，支持分布式架构
跨域能力	难以支持跨域	天然支持跨域请求
安全性	依赖Cookie，存在CSRF风险	支持签名机制，更安全
适用场景	传统MVC应用、小规模系统	REST API、微服务、移动端应用

如表所示，Token机制在分布式系统中具有显著优势。例如，在微服务架构中，多个服务节点无需共享Session，而是通过验证Token中的签名即可确认请求合法性，从而避免了Session复制或集中存储的问题。

2.1.2 Token在无状态认证中的优势

Token机制的无状态特性是其最大优势之一。在传统的Session认证中，服务端需要保存每个用户的登录状态，随着用户量的增加，内存消耗和集群同步问题会变得愈发严重。而Token机制则将用户状态信息存储在客户端，服务端只需验证Token的签名和有效期即可，无需维护会话状态。

例如，在一个电商系统的登录流程中，用户首次登录成功后，服务端生成一个包含用户ID、权限信息、签名等内容的Token，并将其返回给客户端。客户端在后续请求中将该Token放在请求头中，服务端通过解析和验证Token即可完成身份识别，无需依赖Session。

2.1.3 常见的Token类型（如JWT、OAuth2 Token）

Token有多种实现形式，其中最常见的是JWT（JSON Web Token）和OAuth2 Token。

• JWT ：是一种开放标准（RFC 7519），用于在客户端和服务端之间安全地传输信息。JWT由三部分组成：Header、Payload和Signature，通常以Base64Url编码形式传输。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• OAuth2 Token ：是OAuth2协议中用于授权的Token，通常用于第三方应用访问用户资源的场景。它包括Access Token、Refresh Token等类型，常用于社交登录、API访问控制等场景。

Token类型	用途说明	优点
JWT	身份认证、权限传递	可自包含信息，支持签名验证
OAuth2 Token	授权访问第三方资源	支持多授权模式，安全性高

2.2 Token验证的工作流程

Token的验证流程是整个认证机制的核心部分，主要包括Token的生成、携带、解析与验证四个环节。理解这些流程有助于我们更好地设计和实现安全的认证系统。

2.2.1 Token的生成与分发机制

Token的生成通常由认证服务器完成。用户登录成功后，服务器根据用户信息生成一个Token，并将其返回给客户端。生成Token时，通常需要包含以下信息：

• 用户唯一标识（如用户ID）
• 权限信息（如角色、权限列表）
• 签名信息（用于防止篡改）
• 过期时间（用于控制Token的有效期）

以JWT为例，生成Token的Java代码如下：

import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import java.util.Date;

public class TokenGenerator {
    private static final String SECRET_KEY = "mySecretKey";
    private static final long EXPIRATION = 86400000; // 24小时

    public String generateToken(String username) {
        return Jwts.builder()
                .setSubject(username)
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRATION))
                .signWith(SignatureAlgorithm.HS512, SECRET_KEY)
                .compact();
    }
}

代码解释 ：
- setSubject() 设置Token的主题，通常是用户名或用户ID。
- setExpiration() 设置Token的过期时间。
- signWith() 使用指定的算法和密钥对Token进行签名，防止篡改。
- compact() 方法将JWT对象转换为字符串格式。

2.2.2 请求中Token的携带方式

Token通常通过HTTP请求头中的 Authorization 字段进行传输，标准格式如下：

Authorization: Bearer <token>

客户端在每次请求受保护资源时，需要在请求头中携带该Token。例如，使用JavaScript发送一个带有Token的GET请求：

fetch('/api/user', {
    method: 'GET',
    headers: {
        'Authorization': 'Bearer ' + localStorage.getItem('token')
    }
});

参数说明 ：
- Authorization 是标准的HTTP头字段，用于携带认证信息。
- Bearer 表示使用的是Bearer Token（即Token本身）。
- localStorage.getItem('token') 从浏览器本地存储中获取Token值。

2.2.3 服务端对Token的解析与验证流程

服务端接收到请求后，需要对Token进行解析和验证，流程如下：

graph TD
    A[客户端发送请求] --> B[服务端拦截请求]
    B --> C[从请求头获取Token]
    C --> D{Token是否存在?}
    D -- 是 --> E[解析Token内容]
    E --> F{签名是否合法?}
    F -- 是 --> G{Token是否过期?}
    G -- 是 --> H[提取用户信息]
    H --> I[继续处理请求]
    D -- 否 --> J[返回401未授权]
    F -- 否 --> K[返回401签名无效]
    G -- 否 --> L[返回401Token过期]

以JWT为例，Java中验证Token的代码如下：

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jws;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;

public class TokenValidator {
    private static final String SECRET_KEY = "mySecretKey";

    public String validateToken(String token) {
        Jws<Claims> jws = Jwts.parser()
                .setSigningKey(SECRET_KEY)
                .parseClaimsJws(token);
        Claims claims = jws.getBody();
        return claims.getSubject(); // 返回用户名
    }
}

代码解释 ：
- parser() 创建一个JWT解析器。
- setSigningKey() 设置用于验证签名的密钥。
- parseClaimsJws() 解析Token并验证签名。
- getBody() 获取Token中包含的声明（Claims），如用户名、过期时间等。
- 若Token无效或签名不匹配，会抛出异常。

2.3 Token验证的安全性考量

Token机制虽然具备无状态和跨域优势，但在实际应用中仍需注意安全性问题。主要包括签名机制、有效期控制以及传输通道的安全性等。

2.3.1 签名机制与防篡改策略

Token的安全性依赖于签名机制。服务端在生成Token时，使用私钥对Token内容进行签名；客户端在提交Token时，服务端使用相同的密钥进行验证，确保Token未被篡改。

以HMAC-SHA256算法为例，生成和验证签名的过程如下：

String signature = HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secretKey);

逻辑分析 ：
- header 和 payload 是Token的前两部分。
- 使用 HMAC-SHA256 算法对这两部分进行加密签名。
- 最终的Token格式为： base64UrlEncode(header).base64UrlEncode(payload).signature

2.3.2 Token有效期与刷新机制

Token的有效期通常设置为一个较短的时间（如1小时），以降低被盗用的风险。同时，引入Refresh Token机制，允许客户端在Token过期后使用Refresh Token重新获取新的Access Token。

例如，在Spring Security中配置Token过期时间：

security:
  jwt:
    expiration: 3600000 # 1小时
    refresh-expiration: 86400000 # 24小时

参数说明 ：
- expiration ：Access Token的有效期。
- refresh-expiration ：Refresh Token的有效期。

2.3.3 HTTPS在Token传输中的必要性

Token通常以明文形式传输，若未使用HTTPS，Token可能被中间人截取并冒用。因此，在生产环境中，必须使用HTTPS协议传输Token。

例如，在Spring Boot中启用HTTPS：

server:
  port: 8443
  ssl:
    key-store: classpath:keystore.jks
    key-store-password: changeit
    key-store-type: JKS
    key-alias: mydomain

参数说明 ：
- key-store ：密钥库路径。
- key-store-password ：密钥库密码。
- key-alias ：证书别名。

本章深入探讨了Token的基本原理、验证流程与安全性策略，为后续章节中JWT和OAuth2的实践打下了坚实基础。下一章将重点讲解JWT的结构与Java实现，敬请期待。

3. JWT结构解析与验证实现

3.1 JWT的基本结构与组成

JSON Web Token（JWT）是一种开放标准（RFC 7519），用于在网络应用环境中安全地传输信息。它以紧凑的、URL安全的方式传输信息，常用于身份认证和授权。JWT的结构由三部分组成：Header、Payload 和 Signature。每一部分都是 Base64Url 编码的 JSON 数据，三部分通过点号 . 拼接在一起。

3.1.1 Header、Payload、Signature详解

JWT 的三部分结构如下：

组成部分	内容	作用
Header	指定签名算法和令牌类型	用于声明签名算法及令牌类型（如JWT）
Payload	包含实际传输的数据，如用户信息、权限、过期时间等	用于携带有效载荷，包括注册声明、公共声明和私有声明
Signature	使用Header中指定的算法和密钥对Header和Payload进行签名	用于验证消息的完整性和真实性

例如，一个典型的 JWT Header 可能如下：

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

其中：

• "alg" 表示签名算法，常见值有 HS256 （对称加密）和 RS256 （非对称加密）。
• "typ" 表示令牌类型，通常为 JWT 。

Payload 通常包含三种声明（Claims）：

1. Registered Claims （注册声明）：预定义的字段，如 iss （签发者）、 exp （过期时间）、 sub （主题）等。
2. Public Claims （公共声明）：可自定义的标准字段，避免冲突，通常使用 IANA 注册的命名空间。
3. Private Claims （私有声明）：自定义的数据，用于特定业务逻辑。

例如：

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

最后，Signature 是对 Header 和 Payload 的签名，使用 Header 中指定的算法和密钥生成，确保数据未被篡改。

3.1.2 Base64Url编码与解码原理

JWT 中的 Header 和 Payload 都使用 Base64Url 编码，这是一种 URL 安全的 Base64 编码变种，用于避免 URL 中出现非法字符。

Base64Url 编码过程如下：

1. 将原始 JSON 数据转换为 UTF-8 字节流。
2. 使用 Base64 编码该字节流。
3. 替换 Base64 字符串中的 + 为 - ， / 为 _ ，并去掉末尾的 = 。

例如，假设原始 Header 为：

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

转换为 UTF-8 后为字节序列，Base64 编码结果为：

eyJsYW5ndWFnZSI6IkpBViJ9

再经过 Base64Url 编码处理后变为：

eyJsYW5ndWFnZSI6IkpBViJ9

（实际编码过程会更复杂，涉及加密签名等步骤）

3.2 使用Java解析与验证JWT

Java 中可以使用多种库来处理 JWT，如 jjwt 、 auth0-java-jwt 等。下面以 jjwt 为例，演示如何在 Java 中解析和验证 JWT Token。

3.2.1 引入JWT库（如jjwt）

首先，在 pom.xml 中添加 jjwt 依赖：

<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-api</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-impl</artifactId>
    <version>0.11.5</version>
</dependency>
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt-jackson</artifactId>
    <version>0.11.5</version>
</dependency>

3.2.2 解析Token并提取用户信息

以下是一个使用 jjwt 解析 JWT 的示例代码：

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jws;
import io.jsonwebtoken.JwtParser;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import io.jsonwebtoken.security.Keys;
import java.security.Key;

public class JwtUtil {

    private static final Key SECRET_KEY = Keys.secretKeyFor(SignatureAlgorithm.HS256);

    public static void main(String[] args) {
        String token = Jwts.builder()
                .setSubject("user123")
                .claim("name", "Alice")
                .claim("admin", true)
                .signWith(SECRET_KEY)
                .compact();

        System.out.println("Generated Token: " + token);

        // 解析 Token
        JwtParser parser = Jwts.parserBuilder().setSigningKey(SECRET_KEY).build();
        Jws<Claims> jws = parser.parseClaimsJws(token);
        Claims claims = jws.getBody();

        System.out.println("Subject: " + claims.getSubject());
        System.out.println("Name: " + claims.get("name", String.class));
        System.out.println("Is Admin: " + claims.get("admin", Boolean.class));
    }
}

代码解释：

• Jwts.builder() ：构建 JWT。
• .setSubject() ：设置主题（通常是用户ID）。
• .claim() ：添加自定义声明。
• .signWith() ：指定签名密钥。
• .compact() ：生成最终的 JWT 字符串。
• parser.parseClaimsJws(token) ：解析 JWT 并提取 Claims。

3.2.3 验证签名与过期时间

在实际应用中，除了验证签名外，还需要检查 Token 是否过期。可以使用 Claims.getExpiration() 方法获取过期时间，并进行比较：

import java.util.Date;

public class JwtUtil {

    private static final Key SECRET_KEY = Keys.secretKeyFor(SignatureAlgorithm.HS256);

    public static void main(String[] args) {
        Date now = new Date();
        Date expiration = new Date(now.getTime() + 3600 * 1000); // 1小时后过期

        String token = Jwts.builder()
                .setSubject("user123")
                .claim("name", "Alice")
                .claim("admin", true)
                .setExpiration(expiration)
                .signWith(SECRET_KEY)
                .compact();

        JwtParser parser = Jwts.parserBuilder().setSigningKey(SECRET_KEY).build();
        Jws<Claims> jws = parser.parseClaimsJws(token);
        Claims claims = jws.getBody();

        if (claims.getExpiration().before(new Date())) {
            System.out.println("Token 已过期");
        } else {
            System.out.println("Token 有效");
        }
    }
}

参数说明：

• setExpiration(Date) ：设置 Token 的过期时间。
• claims.getExpiration() ：获取 Token 的过期时间。
• before(Date) ：判断当前时间是否早于指定时间。

3.3 自定义JWT生成与验证逻辑

在某些业务场景中，可能需要实现自定义的 JWT 生成与验证逻辑，以满足特定的安全需求。

3.3.1 构建自定义的Payload

你可以根据业务需求构建自定义的 Payload，例如添加用户角色、权限列表等：

String token = Jwts.builder()
        .setSubject("user123")
        .claim("roles", Arrays.asList("ROLE_USER", "ROLE_ADMIN"))
        .claim("permissions", Arrays.asList("read", "write"))
        .setIssuedAt(new Date())
        .setExpiration(expiration)
        .signWith(SECRET_KEY)
        .compact();

3.3.2 使用私钥进行签名

为了提高安全性，建议使用非对称加密算法（如 RS256），并使用私钥签名、公钥验证：

import java.security.KeyPair;
import java.security.KeyPairGenerator;
import java.security.interfaces.RSAPrivateKey;
import java.security.interfaces.RSAPublicKey;

public class JwtUtil {

    private static final KeyPair keyPair = generateRsaKeyPair();

    private static KeyPair generateRsaKeyPair() {
        try {
            KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
            kpg.initialize(2048);
            return kpg.generateKeyPair();
        } catch (Exception e) {
            throw new RuntimeException("Failed to generate RSA key pair", e);
        }
    }

    public static void main(String[] args) {
        String token = Jwts.builder()
                .setSubject("user123")
                .signWith((RSAPrivateKey) keyPair.getPrivate(), SignatureAlgorithm.RS256)
                .compact();

        JwtParser parser = Jwts.parserBuilder()
                .setSigningKey((RSAPublicKey) keyPair.getPublic())
                .build();

        parser.parseClaimsJws(token);
        System.out.println("Token is valid.");
    }
}

3.3.3 在拦截器中集成JWT验证

在 Web 应用中，通常会在拦截器中验证 JWT。以下是基于 Spring Boot 的 JWT 拦截器示例：

@Component
public class JwtInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");

        if (token != null && token.startsWith("Bearer ")) {
            token = token.substring(7);
            try {
                JwtParser parser = Jwts.parserBuilder()
                        .setSigningKey(JwtUtil.SECRET_KEY)
                        .build();
                parser.parseClaimsJws(token);
                return true;
            } catch (JwtException e) {
                response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Invalid Token");
                return false;
            }
        } else {
            response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Missing Token");
            return false;
        }
    }
}

流程图：

graph TD
    A[开始请求] --> B{是否有Token?}
    B -- 是 --> C{Token是否有效?}
    C -- 有效 --> D[允许访问]
    C -- 无效 --> E[返回401]
    B -- 否 --> E

该流程图展示了拦截器中 JWT 的验证逻辑：首先检查是否存在 Token，若存在则解析并验证其签名和有效期，验证通过后允许访问资源，否则返回 401 错误。

---

以上为第三章的完整内容，涵盖了 JWT 的结构、Java 中的解析与验证实现，以及自定义逻辑与拦截器集成的详细说明。

4. OAuth2 access token基本流程

OAuth2 是当前最主流的授权与访问控制协议之一，广泛应用于现代 Web 应用中，尤其是在分布式系统和微服务架构中。本章将从 OAuth2 协议的核心流程出发，深入探讨 Access Token 的获取、使用、校验机制，并通过 Spring Boot 实现 OAuth2 客户端与资源服务器的集成。

4.1 OAuth2协议的核心角色与流程

4.1.1 授权服务器与资源服务器的分工

在 OAuth2 的典型架构中，涉及四个核心角色：

角色名称	描述
资源所有者（Resource Owner）	通常是用户，拥有资源的访问权限。
客户端（Client）	想要访问资源的应用，例如 Web 应用、移动端 App。
授权服务器（Authorization Server）	负责认证用户身份，并颁发 Access Token。
资源服务器（Resource Server）	存储受保护资源的服务器，需验证 Access Token 后提供资源访问。

在实际开发中， 授权服务器 和 资源服务器 可以是两个独立的服务，也可以部署在同一个服务中。例如，在 Spring Security OAuth2 中，可以通过配置将两者集成在一个应用中。

4.1.2 客户端与用户的交互流程

OAuth2 的授权流程大致如下：

graph TD
    A[用户] -->|请求访问资源| B[客户端]
    B -->|重定向到授权页面| C[授权服务器]
    A -->|登录并授权| C
    C -->|返回授权码| B
    B -->|使用授权码换取Access Token| C
    B -->|携带Token访问资源服务器| D[资源服务器]
    D -->|验证Token| C
    D -->|返回资源数据| B

整个流程中，用户通过客户端间接授权访问资源服务器，而不会直接暴露自己的凭证。客户端通过授权服务器获取 Access Token，再将其用于访问资源服务器。

4.2 OAuth2中Access Token的获取与使用

4.2.1 授权码模式与客户端凭证模式

OAuth2 定义了多种授权模式，最常见的包括：

• 授权码模式（Authorization Code） ：适用于第三方应用，如 Web 应用或移动 App。
• 客户端凭证模式（Client Credentials） ：适用于服务间通信，无需用户参与。

授权码模式示例：

1. 客户端引导用户访问授权服务器的 /authorize 接口。
2. 用户登录并授权后，授权服务器将用户重定向回客户端，并携带一个授权码（Authorization Code）。
3. 客户端使用授权码向 /token 接口请求 Access Token。
4. 获取到 Token 后，客户端将其用于访问资源服务器的受保护接口。

客户端凭证模式示例：

1. 客户端向授权服务器发送请求，携带自己的 Client ID 和 Secret。
2. 授权服务器验证客户端身份后，返回 Access Token。
3. 客户端使用 Token 访问资源服务器的受保护接口。

4.2.2 Access Token的请求与响应结构

以客户端凭证模式为例，请求授权服务器获取 Access Token 的代码如下：

import org.springframework.http.*;
import org.springframework.util.LinkedMultiValueMap;
import org.springframework.util.MultiValueMap;
import org.springframework.web.client.RestTemplate;

public class OAuth2Client {

    public static String getAccessToken(String tokenUrl, String clientId, String clientSecret) {
        RestTemplate restTemplate = new RestTemplate();

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
        headers.setBasicAuth(clientId, clientSecret);

        MultiValueMap<String, String> body = new LinkedMultiValueMap<>();
        body.add("grant_type", "client_credentials");

        HttpEntity<MultiValueMap<String, String>> request = new HttpEntity<>(body, headers);

        ResponseEntity<String> response = restTemplate.postForEntity(tokenUrl, request, String.class);

        return response.getBody(); // 返回 JSON 格式的 Access Token
    }
}

代码逻辑分析：

• 使用 RestTemplate 发送 HTTP 请求。
• 设置请求头 Content-Type 为 application/x-www-form-urlencoded 。
• 使用 Basic Auth 传递客户端凭证（Client ID + Secret）。
• 请求体中指定 grant_type 为 client_credentials 。
• 授权服务器返回 JSON 格式的 Token 数据，包含 access_token 、 token_type 、 expires_in 等字段。

示例响应：

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600
}

4.2.3 在Spring Boot中集成OAuth2客户端

Spring Security 提供了对 OAuth2 客户端的集成支持，主要通过 spring-security-oauth2-client 模块实现。

配置示例：

spring:
  security:
    oauth2:
      client:
        registration:
          my-oauth2-client:
            client-id: your-client-id
            client-secret: your-client-secret
            authorization-grant-type: client_credentials
            scope: read,write
        provider:
          my-oauth2-provider:
            token-uri: https://auth-server.com/oauth/token

Java 配置类：

@Configuration
@EnableWebSecurity
public class OAuth2ClientConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .oauth2Client(); // 启用 OAuth2 客户端支持

        return http.build();
    }
}

上述配置将 Spring Boot 应用设置为 OAuth2 客户端，并在访问受保护资源时自动处理 Token 获取与刷新逻辑。

4.3 Access Token的校验与权限映射

4.3.1 资源服务器如何校验Token合法性

资源服务器在接收到客户端请求后，需对携带的 Access Token 进行校验，以确保其合法性。校验方式通常包括：

• 本地校验（JWT Token） ：如果 Token 是 JWT 格式，资源服务器可以自行验证签名和过期时间。
• 远程校验（Opaque Token） ：如果 Token 是不透明的字符串（Opaque Token），资源服务器需向授权服务器发起 /check_token 请求进行校验。

JWT Token 校验示例（使用 jjwt 库）：

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;

public class JwtValidator {

    private static final String SECRET_KEY = "your-secret-key";

    public static boolean validateToken(String token) {
        try {
            Claims claims = Jwts.parser()
                .setSigningKey(SECRET_KEY)
                .parseClaimsJws(token)
                .getBody();

            return !claims.getExpiration().before(new Date());
        } catch (Exception e) {
            return false;
        }
    }
}

代码逻辑分析：

• 使用 Jwts.parser() 解析 Token。
• 设置签名密钥 SECRET_KEY 。
• 检查 Token 是否过期。

4.3.2 将Token信息映射为Spring Security权限

在 Spring Security 中，可以将 Token 中的权限信息转换为 GrantedAuthority ，以便进行权限控制。

示例：从 JWT 中提取权限信息

public class CustomJwtAuthenticationConverter implements Converter<Jwt, AbstractAuthenticationToken> {

    @Override
    public AbstractAuthenticationToken convert(Jwt jwt) {
        Collection<GrantedAuthority> authorities = jwt.getClaimAsStringList("authorities")
            .stream()
            .map(SimpleGrantedAuthority::new)
            .collect(Collectors.toList());

        return new JwtAuthenticationToken(jwt, authorities);
    }
}

配置类中启用：

@Configuration
@EnableWebSecurity
public class ResourceServerConfig {

    @Bean
    public SecurityFilterChain resourceServerFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
            .anyRequest().authenticated()
            .and()
            .oauth2ResourceServer()
            .jwt()
            .jwtAuthenticationConverter(customJwtAuthenticationConverter());

        return http.build();
    }

    @Bean
    public CustomJwtAuthenticationConverter customJwtAuthenticationConverter() {
        return new CustomJwtAuthenticationConverter();
    }
}

4.3.3 使用Opaque Token与JWT Token的对比

特性	Opaque Token	JWT Token
可读性	不可读，为随机字符串	可读，结构清晰
签名验证	需远程验证	可本地验证
安全性	依赖授权服务器	依赖签名机制
性能	每次请求需远程校验	本地校验，性能高
适用场景	中心化授权架构	分布式微服务架构

在实际应用中， JWT Token 更适合分布式系统 ，因为其具备自包含性和可本地校验的特性，而 Opaque Token 更适合中心化架构，便于统一管理 Token 状态。

至此，本章详细介绍了 OAuth2 协议中 Access Token 的获取、使用与校验机制，并通过 Java 代码示例和 Spring Boot 配置展示了 OAuth2 客户端与资源服务器的实现方式。下一章将聚焦于 Spring Security 提供的注解式权限控制，进一步深入探讨方法级别的访问控制策略。

5. Spring Security注解权限控制

在构建现代Web应用时，权限控制不仅限于URL级别的访问限制，更需要在业务方法层面实现精细化的访问控制。Spring Security 提供了多种注解机制，允许开发者在方法级别上实现权限控制。这些注解不仅提高了代码的可读性和可维护性，还为细粒度的安全控制提供了良好的支持。

本章将深入探讨 Spring Security 中的注解权限控制机制，重点分析 @Secured 和 @PreAuthorize 的使用方式，并通过代码示例展示如何在实际项目中启用和使用这些注解。此外，还将介绍如何将注解与 Spring Security 的安全上下文进行整合，确保在方法调用过程中能够正确执行权限校验逻辑。

5.1 Spring Security注解的基本作用

5.1.1 方法级安全控制的引入

传统的权限控制通常基于 URL 路径，例如使用 http.authorizeRequests() 方法来限制特定路径的访问权限。然而，随着业务逻辑的复杂化，仅靠 URL 控制已经无法满足需求。例如，在同一个 Controller 方法中，不同角色可能需要不同的操作权限；或者在服务层中对某个业务方法进行访问控制。

Spring Security 提供了方法级别的安全控制能力，通过在方法上添加注解，开发者可以在业务逻辑执行前进行权限判断。这种方式使得权限控制更加贴近业务逻辑，提高了安全性和灵活性。

5.1.2 注解在权限控制中的优势

相比传统的 URL 权限控制方式，使用注解有以下优势：

优势点	描述
细粒度控制	可以精确到方法级别，甚至方法参数级别
与业务逻辑解耦	权限控制逻辑与业务逻辑分离，提高可维护性
增强可读性	开发者可以直接在方法上看到权限要求
支持 SpEL 表达式	使用 @PreAuthorize 可以通过 SpEL 实现动态权限判断
支持多注解混合使用	不同注解可以组合使用，实现更复杂的权限策略

5.2 注解的启用与配置

5.2.1 启用方法安全的配置方式

在 Spring Boot 项目中，默认情况下，方法级别的安全控制是禁用的。要启用该功能，需要在配置类中添加 @EnableGlobalMethodSecurity 注解。

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration {
}

• prePostEnabled = true ：启用 @PreAuthorize 和 @PostAuthorize 注解。
• securedEnabled = true ：启用 @Secured 注解。

这样配置后，Spring Security 就会在方法调用时自动进行权限校验。

5.2.2 配置全局权限表达式处理器

Spring Security 使用 PermissionEvaluator 来处理权限表达式。如果项目中使用了自定义的权限判断逻辑，可以通过实现 PermissionEvaluator 接口并注册到 Spring 容器中。

@Component
public class CustomPermissionEvaluator implements PermissionEvaluator {

    @Override
    public boolean hasPermission(Authentication authentication, Object targetDomainObject, Object permission) {
        // 自定义权限判断逻辑
        return false;
    }

    @Override
    public boolean hasPermission(Authentication authentication, Serializable targetId, String targetType, Object permission) {
        return false;
    }
}

然后在配置类中将其注册为 Bean：

@Bean
public MethodSecurityExpressionHandler methodSecurityExpressionHandler() {
    DefaultMethodSecurityExpressionHandler handler = new DefaultMethodSecurityExpressionHandler();
    handler.setPermissionEvaluator(new CustomPermissionEvaluator());
    return handler;
}

5.3 注解与安全上下文的整合

5.3.1 方法执行时的权限验证机制

Spring Security 在方法调用时会通过 AOP 拦截目标方法，并在执行前进行权限校验。校验的核心逻辑依赖于当前用户的 Authentication 对象，以及方法上的注解表达式。

例如，使用 @PreAuthorize("hasRole('ADMIN')") 时，Spring 会解析 SpEL 表达式，调用 SecurityExpressionRoot 中的方法判断用户是否具有 ADMIN 角色。

其流程图如下：

graph TD
    A[方法调用] --> B{是否有权限注解?}
    B -->|是| C[获取当前Authentication]
    C --> D[解析SpEL表达式]
    D --> E[执行权限判断]
    E -->|通过| F[执行方法体]
    E -->|不通过| G[抛出AccessDeniedException]
    B -->|否| F

5.3.2 结合Authentication和Principal的使用

在权限校验过程中，Spring Security 会从 SecurityContextHolder 中获取当前用户的 Authentication 对象，并从中提取 Principal （用户身份）以及权限信息。

例如，可以结合 Principal 对象进行参数级别的权限控制：

@PreAuthorize("#userId == authentication.principal.userId or hasRole('ADMIN')")
public User getUserById(Long userId) {
    return userRepository.findById(userId);
}

上面的注解表示：如果当前用户 ID 与方法参数中的 userId 一致，或者用户具有 ADMIN 角色，则允许访问。

这段代码的逐行分析如下：

• #userId ：表示方法参数中的 userId 值；
• authentication.principal.userId ：表示当前用户的 ID；
• or hasRole('ADMIN') ：表示用户具有 ADMIN 角色也可以访问；
• @PreAuthorize(...) ：在方法执行前进行权限校验。

示例：在 Controller 中使用注解进行权限控制

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    @PreAuthorize("#id == authentication.principal.userId or hasRole('ADMIN')")
    public ResponseEntity<User> getUser(@PathVariable Long id) {
        return ResponseEntity.ok(userService.getUserById(id));
    }

    @PostMapping
    @Secured("ROLE_ADMIN")
    public ResponseEntity<User> createUser(@RequestBody User user) {
        return ResponseEntity.ok(userService.createUser(user));
    }
}

• @PreAuthorize 用于动态判断当前用户是否有权限访问指定用户信息；
• @Secured 用于限制只有 ADMIN 角色可以创建用户；
• authentication.principal.userId 是从安全上下文中提取的用户 ID；
• hasRole('ADMIN') 判断用户是否具有管理员权限。

小结与延伸

通过本章内容可以看出，Spring Security 的注解权限控制机制极大地增强了权限控制的灵活性和可维护性。无论是使用 @Secured 进行简单角色控制，还是使用 @PreAuthorize 结合 SpEL 实现动态权限判断，都可以有效提升系统的安全性。

在下一章中，我们将深入讲解 @Secured 与 @PreAuthorize 的具体使用方法，并通过多个实际案例展示如何在不同业务场景中灵活运用这些注解来实现更精细的权限控制。

6. @Secured与@PreAuthorize注解使用方法

Spring Security 提供了多种方式来实现方法级别的安全控制，其中 @Secured 和 @PreAuthorize 是最常用的两种注解方式。它们可以帮助开发者在业务逻辑层面进行权限控制，实现更细粒度的安全策略。本章将详细讲解这两个注解的使用方法、适用场景以及它们与 URL 路径权限控制的对比。

6.1 @Secured注解的使用场景

@Secured 是 Spring Security 提供的一个早期方法级权限控制注解，适用于基于角色的访问控制。

6.1.1 限制方法调用的角色权限

@Secured 支持通过指定角色来限制方法的访问权限。例如：

@Secured("ROLE_ADMIN")
public void deleteUser(Long userId) {
    // 删除用户逻辑
}

上述代码表示只有拥有 ROLE_ADMIN 角色的用户才能调用 deleteUser 方法。

⚠️ 注意： @Secured 不支持 Spring Expression Language（SpEL），只能使用简单的角色名进行判断。

6.1.2 启用@Secured支持的配置

要在 Spring Boot 项目中启用 @Secured ，需要在配置类中添加 @EnableGlobalMethodSecurity(securedEnabled = true) 注解：

@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(securedEnabled = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    // 配置内容
}

6.1.3 示例：在Controller中使用@Secured

@RestController
@RequestMapping("/users")
public class UserController {

    @Secured("ROLE_ADMIN")
    @DeleteMapping("/{id}")
    public ResponseEntity<?> deleteUser(@PathVariable Long id) {
        return ResponseEntity.ok("用户 " + id + " 已删除");
    }
}

此示例中，只有具备 ROLE_ADMIN 角色的用户才能执行删除用户操作。

6.2 @PreAuthorize注解的高级用法

@PreAuthorize 是基于 SpEL 表达式的更强大的方法级权限控制注解，支持更复杂的权限判断逻辑。

6.2.1 支持SpEL表达式进行细粒度控制

@PreAuthorize 允许在注解中编写 SpEL 表达式，例如：

@PreAuthorize("hasRole('ADMIN') and #userId < 1000")
public void deleteUser(@Param("userId") Long userId) {
    // 删除用户逻辑
}

此方法表示只有角色为 ADMIN 且 userId 小于 1000 的情况下，才允许调用该方法。

6.2.2 动态权限判断与方法参数校验

可以结合方法参数进行动态权限判断，例如：

@PreAuthorize("#userId == authentication.principal.userId or hasRole('ADMIN')")
public User getUserById(@PathVariable Long userId) {
    return userRepository.findById(userId);
}

这段代码表示只有用户自己或管理员才能查看该用户信息。

6.2.3 示例：结合hasAuthority和hasRole的判断

@PreAuthorize("hasAuthority('DELETE_USER') or hasRole('SUPER_ADMIN')")
public void deleteUser(Long userId) {
    // 删除逻辑
}

该示例表示具备 DELETE_USER 权限或 SUPER_ADMIN 角色的用户均可调用此方法。

✅ @PreAuthorize 是推荐使用的注解，因为它支持 SpEL，具备更高的灵活性和可读性。

6.3 注解方式与URL路径控制的对比

在 Spring Security 中，除了使用注解进行方法级权限控制外，还可以通过 URL 路径进行权限控制。

6.3.1 URL路径控制的配置方式

在配置类中通过 HttpSecurity 对 URL 路径进行限制：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
            .antMatchers("/users/**").hasRole("ADMIN")
            .antMatchers("/profile/**").authenticated()
            .anyRequest().permitAll()
        .and()
        .formLogin();
}

这种方式适合对整个控制器或接口路径进行统一权限控制。

6.3.2 注解方式的优势与适用场景

对比维度	URL路径控制	注解方式
控制粒度	粗（路径级别）	细（方法级别）
灵活性	一般	高（支持SpEL）
可维护性	集中配置，便于统一管理	分散在代码中，需注意代码可读性
适用场景	公共接口、基础权限控制	业务逻辑复杂、需动态判断权限

6.3.3 综合使用注解与配置实现细粒度权限控制

在实际项目中，通常将 URL 路径控制与方法注解结合使用。例如：

• URL 路径控制保证基本的安全边界；
• 方法注解实现业务逻辑中的动态权限判断。

@Configuration
@EnableWebSecurity
@EnableGlobalMethodSecurity(prePostEnabled = true, securedEnabled = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    // 配置内容
}

这样可以同时启用 @Secured 和 @PreAuthorize ，结合 URL 路径控制，构建一个全面、灵活的安全体系。

（本章内容完）

本文还有配套的精品资源，点击获取

简介：在Java Web开发中，保障接口安全至关重要。本文围绕Token验证和基于注解的权限管理两大核心安全机制展开，详细介绍了如何通过JWT和OAuth2实现无状态身份认证，并利用Spring Security的 @Secured 、 @PreAuthorize 等注解灵活控制接口访问权限。配套代码示例涵盖Token解析、签名验证、过期处理及安全配置类，帮助开发者快速集成安全功能，提升系统安全性。

本文还有配套的精品资源，点击获取