1. 引言在 Java Web 开发中Apache Shiro 和 Spring Security 是最广为人知的两大安全框架。然而在实际企业级项目中还存在多种其他常见的安全认证与授权架构方案它们各有适用场景和优劣。本文将从架构选型角度系统梳理 Shiro、Spring Security 之外的常见认证授权架构并针对这些架构给出渗透测试的思路与关注点。常见安全架构中 Shiro 的认证确认机制解析-CSDN博客https://blog.csdn.net/2503_91800161/article/details/166010842?spm1001.2014.3001.5501https://blog.csdn.net/2503_91800161/article/details/166010842?spm1001.2014.3001.5501https://blog.csdn.net/2503_91800161/article/details/166010842?spm1001.2014.3001.5501除了 Shiro 还有什么常见架构Spring Security 详解-CSDN博客https://blog.csdn.net/2503_91800161/article/details/166492353?spm1001.2014.3001.5501https://blog.csdn.net/2503_91800161/article/details/166492353?spm1001.2014.3001.5501https://blog.csdn.net/2503_91800161/article/details/166492353?spm1001.2014.3001.55012. 常见认证授权架构概览除了 Shiro 和 Spring Security常见的认证授权架构可以归纳为以下几类基于 JWT 的无状态认证架构适用于前后端分离、微服务场景。基于 OAuth2 / OIDC 的统一授权架构适用于第三方登录、开放平台、多应用统一认证。基于 API 网关的统一认证架构在网关层集中处理认证鉴权后端服务无感知。基于 Session 的传统单体认证架构适用于传统单体应用配合 Redis 做分布式会话。基于自定义 Filter / 拦截器的轻量认证架构适用于简单场景或框架受限的遗留系统。基于 Service Mesh 的零信任认证架构适用于云原生、Kubernetes 环境下的服务间认证。3. 基于 JWT 的无状态认证架构3.1 架构原理JWTJSON Web Token认证架构的核心思想是服务端不再保存会话状态而是将用户身份信息、权限信息签名后发放给客户端客户端在后续请求中携带该 Token服务端验签后即可信任其身份。一个典型的 JWT 认证流程如下用户提交用户名密码服务端校验通过后生成 JWT 返回给客户端。客户端将 JWT 存储在本地localStorage 或 Cookie。客户端每次请求在 Authorization 头中携带 Bearer Token。服务端通过拦截器或过滤器解析并验签 JWT获取用户身份和权限。3.2 常见实现框架Java JWTjjwt轻量级 JWT 生成与解析库。Nimbus JOSE JWT功能全面的 JOSE 实现支持多种签名算法。Auth0 java-jwtAuth0 官方 Java 库使用简单。Spring Security JWT在 Spring Security 基础上扩展 JWT 过滤器。3.3 基于 jjwt 的 Java 实战示例下面以 jjwt 库为例演示 JWT 的生成、解析验签和过期时间设置三个核心方法。示例使用 HS256 对称签名算法密钥通过环境变量注入避免硬编码泄露。import io.jsonwebtoken.Claims; import io.jsonwebtoken.Jwts; import io.jsonwebtoken.SignatureAlgorithm; import io.jsonwebtoken.security.Keys; import javax.crypto.SecretKey; import java.nio.charset.StandardCharsets; import java.util.Date; public class JwtUtil { // 从环境变量读取密钥避免硬编码泄露生产环境建议使用密钥管理服务 private static final SecretKey SECRET_KEY Keys.hmacShaKeyFor( System.getenv(JWT_SECRET).getBytes(StandardCharsets.UTF_8)); // 默认过期时间2 小时 private static final long EXPIRE_MILLIS 2 * 60 * 60 * 1000L; /** 生成 JWT Token param userId 用户 ID param username 用户名 param role 角色 return 签名后的 JWT 字符串 */ public static String generateToken(String userId, String username, String role) { Date now new Date(); Date expireAt new Date(now.getTime() EXPIRE_MILLIS); return Jwts.builder() .setSubject(userId) // 主题用户 ID .claim(username, username) // 自定义声明用户名 .claim(role, role) // 自定义声明角色 .setIssuedAt(now) // 签发时间 .setExpiration(expireAt) // 过期时间 .signWith(SECRET_KEY, SignatureAlgorithm.HS256) // 使用 HS256 签名 .compact(); } /** 解析并验签 JWT Token param token JWT 字符串 return 解析后的 Claims包含用户信息 throws io.jsonwebtoken.JwtException 签名无效或 Token 被篡改时抛出 */ public static Claims parseToken(String token) { return Jwts.parserBuilder() .setSigningKey(SECRET_KEY) // 设置验签密钥 .build() .parseClaimsJws(token) // 验签并解析 .getBody(); } /** 校验 Token 是否有效验签 过期时间 param token JWT 字符串 return true 表示有效false 表示无效或已过期 */ public static boolean validateToken(String token) { try { parseToken(token); return true; } catch (io.jsonwebtoken.ExpiredJwtException e) { // Token 已过期可在此记录日志并提示重新登录 System.err.println(Token 已过期: e.getMessage()); return false; } catch (io.jsonwebtoken.JwtException e) { // 签名无效、Token 被篡改或格式错误 System.err.println(Token 校验失败: e.getMessage()); return false; } } }使用示例登录成功后调用generateToken生成 Token 返回给客户端后续请求中调用validateToken校验有效性通过后调用parseToken获取用户 ID、角色等信息用于鉴权。需要注意parseToken在 Token 过期或签名被篡改时会抛出异常因此生产代码中应统一捕获ExpiredJwtException和JwtException避免异常信息直接暴露给前端。3.3 优缺点分析优点无状态服务端无需存储会话天然支持水平扩展。适合前后端分离、移动端、微服务等跨域场景。Token 自包含用户信息和权限减少数据库查询。缺点Token 一旦签发在有效期内难以主动吊销存在安全风险。Token 体积较大每次请求都会增加网络开销。密钥管理要求高密钥泄露将导致全线失守。4. 基于 OAuth2 / OIDC 的统一授权架构4.1 架构原理OAuth2 是一种授权框架核心思想是资源所有者将资源的访问权限委托给第三方应用而不需要向第三方应用暴露自己的凭证。OIDCOpenID Connect在 OAuth2 之上增加了身份认证层用于验证用户身份。典型流程如下客户端引导用户跳转到授权服务器。用户在授权服务器上登录并授权。授权服务器返回授权码给客户端。客户端用授权码换取访问令牌Access Token和 ID Token。客户端携带 Access Token 访问资源服务器。4.2 常见实现框架Spring Authorization ServerSpring 官方 OAuth2 授权服务器。Keycloak开源身份认证与访问管理平台功能强大。Apache OltuApache 旗下的 OAuth2 实现。Nimbus OAuth2轻量级 OAuth2 客户端与服务器实现。4.3 优缺点分析优点支持第三方登录、开放平台、多应用统一认证等复杂场景。授权与认证分离权限模型清晰。生态成熟有大量现成实现和标准规范。缺点架构复杂部署和运维成本较高。授权服务器成为新的单点需要高可用设计。协议细节多实现不当容易引入安全漏洞。5. 基于 API 网关的统一认证架构5.1 架构原理在微服务架构中API 网关作为所有请求的统一入口在网关层集中完成认证、鉴权、限流、审计等横切关注点。后端微服务不再各自实现认证逻辑而是信任网关传递过来的用户身份信息。典型流程如下客户端请求先到达 API 网关。网关校验 Token 或 Session完成身份认证。网关将用户身份信息如用户 ID、角色写入请求头转发给后端服务。后端服务从请求头中读取身份信息进行业务处理。5.2 常见实现框架Spring Cloud GatewaySpring 生态的响应式网关。Kong Gateway基于 Nginx 的开源 API 网关。APISIX云原生 API 网关支持丰富的插件。Nginx Lua通过 OpenResty 实现自定义认证逻辑。5.3 优缺点分析优点认证逻辑集中管理后端服务开发简单。便于统一实施安全策略如限流、黑白名单、审计日志。适合大规模微服务架构扩展性好。缺点网关成为性能瓶颈和单点故障需要高可用设计。网关与后端服务之间的信任传递需要额外安全机制。网关层配置复杂运维门槛较高。6. 基于 Session 的传统认证架构6.1 架构原理传统 Session 认证架构中用户登录成功后服务端创建 Session 并保存会话状态同时将 Session ID 通过 Cookie 返回给客户端。客户端后续请求携带 Cookie服务端根据 Session ID 查找会话状态完成认证。在分布式场景下通常使用 Redis 等外部存储保存 Session实现会话共享。6.2 常见实现框架Servlet 原生 SessionJava Web 容器自带的会话管理。Spring SessionSpring 提供的分布式会话管理方案。Redis 自定义 Session 过滤器手动实现会话存储与校验。6.3 优缺点分析优点实现简单技术成熟学习成本低。服务端可主动控制会话生命周期便于吊销。适合传统单体应用和内部管理系统。缺点有状态服务端需要保存会话水平扩展受限。依赖 Cookie跨域场景处理复杂。Session 固定、会话劫持等攻击面需要额外防护。7. 基于自定义 Filter / 拦截器的轻量认证架构7.1 架构原理在一些遗留系统或框架受限的场景下开发者会通过 Servlet Filter 或 Spring 拦截器手动实现认证逻辑。这种方式不依赖任何安全框架完全由开发者控制认证流程。典型实现包括编写一个认证过滤器拦截所有请求。从请求头、Cookie 或参数中提取凭证。校验凭证有效性通过则放行否则返回 401。将用户信息放入 ThreadLocal 或请求上下文供业务层使用。7.2 优缺点分析优点灵活可控不引入额外依赖适合轻量场景。便于在遗留系统中逐步改造。缺点安全逻辑完全依赖开发者经验容易遗漏防护点。缺乏统一的权限模型和注解支持代码重复度高。维护成本高安全升级需要人工跟进。8. 基于 Service Mesh 的零信任认证架构8.1 架构原理在云原生环境中Service Mesh如 Istio、Linkerd通过 Sidecar 代理实现服务间通信的加密、认证和授权。每个服务实例旁边部署一个 Sidecar所有进出流量都经过 Sidecar由控制平面统一下发安全策略。典型能力包括mTLS 双向认证服务间通信自动加密并验证身份。基于身份的访问控制通过 AuthorizationPolicy 定义服务间访问规则。细粒度流量管控结合 JWT 校验实现请求级鉴权。8.2 优缺点分析优点安全能力下沉到基础设施层业务代码无侵入。支持零信任模型服务间默认不信任需显式授权。适合大规模微服务和 Kubernetes 环境。缺点引入额外基础设施部署和运维复杂度高。性能开销增加需要合理规划资源。技术栈较新团队需要一定学习成本。9. 各架构选型对比架构方案适用场景状态管理复杂度扩展性JWT 无状态认证前后端分离、微服务、移动端无状态中高OAuth2 / OIDC第三方登录、开放平台、统一认证有状态授权码高高API 网关统一认证大规模微服务架构视实现而定中高高Session 传统认证单体应用、内部系统有状态低中自定义 Filter 认证遗留系统、轻量场景视实现而定低低Service Mesh 零信任云原生、Kubernetes无状态mTLS高高10. 渗透测试思路与关注点10.1 通用渗透测试思路无论采用哪种认证架构渗透测试都应从以下几个层面展开信息收集识别认证机制类型、Token 格式、Cookie 属性、登录接口等。身份认证绕过尝试弱口令、默认凭证、暴力破解、验证码绕过等。会话管理测试检查 Session 固定、会话过期、Token 泄露、Cookie 安全属性等。授权绕过测试尝试越权访问、水平越权、垂直越权、IDOR 等。加密与签名测试检查算法强度、密钥管理、签名校验是否可绕过。10.2 JWT 架构渗透重点算法混淆攻击尝试将 RS256 改为 HS256使用公钥作为 HMAC 密钥进行签名。弱密钥爆破使用常见弱密钥字典对 JWT 签名进行爆破。Token 篡改修改 payload 中的用户 ID、角色等字段观察服务端是否校验签名。过期时间绕过将 exp 字段改为未来时间观察服务端是否校验。密钥泄露检查前端代码、配置文件、Git 仓库中是否泄露签名密钥。10.3 OAuth2 / OIDC 渗透重点授权码劫持检查 redirect_uri 是否可被篡改尝试劫持授权码。攻击场景授权服务器未严格校验 redirect_uri攻击者将回调地址篡改为自己控制的域名如 https://evil.com/callback诱导受害者点击恶意链接完成授权授权码便会发送到攻击者服务器攻击者随即用该授权码换取 Access Token实现账号接管。防御建议授权服务器必须对 redirect_uri 做白名单精确匹配禁止使用前缀匹配或包含匹配客户端应使用 PKCEProof Key for Code Exchange机制通过 code_verifier 与 code_challenge 绑定授权码即使授权码被截获也无法兑换 Token。实战案例某开放平台授权服务器仅校验 redirect_uri 是否包含合法域名前缀攻击者构造 https://legit.com.evil.com/callback 成功通过校验。攻击步骤第一步攻击者在自己的服务器上部署回调页面记录收到的授权码第二步构造恶意授权链接 https://auth.legit.com/oauth/authorize?client_idapp123redirect_urihttps://legit.com.evil.com/callbackresponse_typecode并通过钓鱼邮件诱导受害者点击第三步受害者在授权服务器上完成登录授权后授权码被发送到攻击者服务器第四步攻击者使用截获的授权码向令牌端点发起请求换取 Access Token。预期结果攻击者成功获取受害者的 Access Token可读取其个人资料、订单等敏感数据实现账号接管。修复建议授权服务器对 redirect_uri 采用精确白名单匹配拒绝任何包含子域名、路径拼接或编码变体的回调地址客户端启用 PKCE将 code_challenge 与授权码绑定即使授权码泄露也无法兑换 Token同时缩短授权码有效期并限制单次使用。CSRF 攻击检查 state 参数是否存在缺失则存在 CSRF 风险。攻击场景授权请求未携带 state 参数攻击者预先构造一个合法的授权链接诱导已登录用户点击使受害者在不知情的情况下完成授权攻击者随后利用该授权码绑定自己的客户端从而获取受害者的资源访问权限。防御建议客户端在发起授权请求时必须生成并携带随机的 state 参数授权服务器在回调时原样返回该参数客户端校验回调中的 state 与发起时是否一致不一致则拒绝处理同时建议将 state 与用户会话绑定并设置合理的有效期。实战案例某应用在 OAuth2 授权流程中未生成 state 参数攻击者利用该缺陷实施 CSRF 攻击。攻击步骤第一步攻击者以受害者身份向授权服务器发起授权请求获取一个合法的授权链接第二步攻击者将该链接嵌入恶意网页或邮件中诱导已登录的受害者点击第三步受害者在不知情的情况下完成授权授权码被发送到攻击者指定的回调地址第四步攻击者使用该授权码绑定自己的客户端获取受害者的资源访问权限。预期结果攻击者成功将受害者的账号授权给攻击者控制的客户端可长期访问受害者的受保护资源且受害者难以察觉。修复建议客户端在发起授权请求时生成高强度随机 state 值并存入会话回调时严格比对 state 是否一致不一致立即终止流程授权服务器应要求客户端必须携带 state 参数缺失则拒绝授权请求同时建议将 state 与用户会话绑定并设置短有效期降低被利用的风险。Token 泄露检查 Access Token 是否在 URL、日志、Referer 中泄露。Scope 越权尝试申请超出预期的 scope 权限。ID Token 校验缺失检查服务端是否正确校验 ID Token 的签名和 audience。10.4 API 网关架构渗透重点网关绕过尝试直接访问后端服务端口绕过网关认证。攻击场景在微服务架构中API 网关是唯一对外暴露的入口后端微服务通常部署在内网并监听独立端口如 8080、9090。若后端服务直接绑定在 0.0.0.0 且未配置防火墙或网络安全组限制来源 IP攻击者可通过端口扫描发现后端服务地址绕过网关直接访问后端接口从而跳过网关层的认证、鉴权和审计。防御建议后端服务应仅绑定内网地址或 127.0.0.1并通过防火墙、安全组、网络策略NetworkPolicy限制仅允许网关所在网段访问同时后端服务自身也应实现认证鉴权不能完全信任网关传递的身份信息。实战案例某电商平台将订单服务部署在 10.0.0.5:8080仅网关对外暴露 443 端口但安全组误放行了 0.0.0.0/0 对 8080 端口的入站流量。攻击步骤第一步攻击者使用 Nmap 对目标网段进行端口扫描发现 10.0.0.5:8080 开放第二步攻击者直接向 http://10.0.0.5:8080/api/orders 发起请求未携带任何 Token第三步后端订单服务未做认证校验直接返回了订单数据。预期结果攻击者无需登录即可读取所有用户的订单信息造成严重的数据泄露。修复建议通过安全组或防火墙仅允许网关 IP 访问后端服务端口后端服务绑定内网地址并启用服务间认证如 mTLS 或内部 Token同时后端服务自身必须实现认证鉴权不能仅依赖网关层校验。请求头伪造尝试伪造 X-User-ID、X-Role 等身份头观察后端是否信任。路径穿越尝试通过路径编码、大小写变换等方式绕过网关路由规则。网关配置错误检查网关是否开放了未预期的管理接口或调试接口。10.5 Session 架构渗透重点Session 固定攻击尝试在登录前设置 Session ID登录后观察是否复用。Cookie 安全属性检查 Cookie 是否设置 HttpOnly、Secure、SameSite 属性。会话并发与过期测试会话是否支持并发登录、过期时间是否合理。Redis 未授权访问若使用 Redis 存储 Session检查 Redis 是否可未授权访问。10.6 自定义 Filter 架构渗透重点过滤器遗漏路径尝试访问未纳入过滤器拦截范围的路径。静态资源绕过尝试通过静态资源路径绕过认证。请求方法绕过尝试使用 OPTIONS、HEAD 等方法绕过认证逻辑。参数污染尝试通过重复参数、编码差异绕过校验。11. 总结Shiro 和 Spring Security 是 Java Web 领域最主流的安全框架但并非唯一选择。JWT 无状态认证、OAuth2 / OIDC 统一授权、API 网关统一认证、Session 传统认证、自定义 Filter 认证以及 Service Mesh 零信任架构都是实际项目中常见的认证授权方案。每种架构都有其适用场景和固有风险安全测试人员需要针对不同架构的特点制定差异化的渗透测试策略重点关注认证绕过、授权越权、Token 安全、会话管理和密钥管理等方面。
