PAC4J v5.4.3 JwtAuthenticator过期JWT错误日志优化方案咨询

问题背景 #

我们的Java应用使用PAC4J v5.4.3版本，通过默认JwtAuthenticator搭配DirectBasicAuthClient实现API请求认证，JWT有效期设为30分钟。当JWT过期后，系统会持续输出ERROR级别日志：

2023-02-06T08:02:24.557 ERROR [qtp1368888679-667] org.pac4j.jwt.credentials.authenticator.JwtAuthenticator - The JWT is expired: no profile is built

这类日志导致监控系统混淆并误报警，我们希望将JWT过期场景的日志级别降低，不将其视为真正的“错误”。

最优方案：调整日志配置（无需修改代码） #

直接通过日志框架配置，将JwtAuthenticator类的日志级别从ERROR调整为WARN或INFO，这是最简洁、无侵入的解决方案。

以Logback为例，在logback.xml中添加如下配置：

<!-- 针对JwtAuthenticator单独调整日志级别 -->
<logger name="org.pac4j.jwt.credentials.authenticator.JwtAuthenticator" level="WARN" additivity="false">
    <appender-ref ref="YOUR_APPENDER_NAME"/>
</logger>

如果使用Log4j2，配置逻辑类似：

<Logger name="org.pac4j.jwt.credentials.authenticator.JwtAuthenticator" level="warn" additivity="false">
    <AppenderRef ref="YOUR_APPENDER_NAME"/>
</Logger>

配置生效后，JWT过期的日志会以WARN级别输出，不会触发监控系统的错误报警规则。

备选方案：自定义异常处理 #

如果无法调整全局日志配置，可以在认证流程中捕获JWT过期异常（ExpiredJwtException），自定义日志输出逻辑：

1. 在项目的PAC4J认证拦截器/过滤器中，捕获认证过程抛出的ExpiredJwtException
2. 以WARN级别记录该异常，替代JwtAuthenticator默认的ERROR日志
3. 正常返回401未授权响应

示例伪代码：

try {
    // 执行PAC4J认证逻辑
    profileManager.get(true);
} catch (ExpiredJwtException e) {
    logger.warn("JWT已过期: {}", e.getMessage());
    response.sendError(HttpServletResponse.SC_UNAUTHORIZED, "Token expired");
}

备选方案：重写JwtAuthenticator #

如果上述方案均不可行，再考虑重写JwtAuthenticator的createJwtProfile方法，修改日志输出级别：

public class CustomJwtAuthenticator extends JwtAuthenticator {
    private static final Logger logger = LoggerFactory.getLogger(CustomJwtAuthenticator.class);

    @Override
    protected Optional<UserProfile> createJwtProfile(JwtCredentials credentials, String token) {
        try {
            return super.createJwtProfile(credentials, token);
        } catch (ExpiredJwtException e) {
            logger.warn("The JWT is expired: no profile is built");
            return Optional.empty();
        }
    }
}

之后在PAC4J配置中，将默认的JwtAuthenticator替换为自定义实现即可。

方案对比 #

• 日志配置：最优方案，无代码侵入，维护成本最低
• 自定义异常处理：适合需要对过期逻辑做额外业务处理的场景（比如关联用户ID记录）
• 重写Authenticator：侵入性较强，仅在其他方案不可行时使用

内容的提问来源于stack exchange，提问作者Anthony Lee