JHipster中JWT配置定义方法及微服务认证失败问题排查

JHipster其实已经帮咱们搭好了JWT的基础框架，你主要通过这几个关键地方来定义或调整配置：

• 配置文件（application.yml/application.properties）：这是最直观的配置入口，核心参数包括：
  • jhipster.security.authentication.jwt.base64-secret：JWT签名用的Base64编码密钥，生产环境一定要用强随机密钥，JHipster初始化项目时会自动生成一个，你可以替换成自己的。
  • jhipster.security.authentication.jwt.token-validity-in-seconds：Token的有效期，默认是86400秒（24小时），按需调整即可。
  • jhipster.security.authentication.jwt.token-validity-in-seconds-for-remember-me：勾选“记住我”时的Token有效期，默认是2592000秒（30天）。
    给你个application.yml的示例：

  jhipster:
    security:
      authentication:
        jwt:
          base64-secret: your-strong-base64-encoded-secret-here
          token-validity-in-seconds: 86400
          token-validity-in-seconds-for-remember-me: 2592000
  

• 核心配置类：JHipster生成的SecurityConfiguration和JWTConfigurer是控制JWT认证逻辑的核心。比如你想加额外的Token校验规则，或者自定义Token解析逻辑，就可以在JWTConfigurer的configure方法里调整JWTFilter的行为，甚至添加自己的过滤器。
• 自定义Token处理：如果需要给Token加额外的自定义信息（比如用户部门ID、权限详情），可以修改TokenProvider类——这个类负责Token的创建、解析和校验。在它的createToken方法里，你可以往Claims里添加自定义字段，满足业务需求。

遇到这个未授权的问题，咱们一步步来排查，大概率是配置不一致或者请求传递的问题：

• 先核对JWT密钥是否完全一致
  网关和所有微服务的jhipster.security.authentication.jwt.base64-secret必须完全相同！如果网关用的密钥和Web API不一样，API根本解析不了网关转发过来的Token，直接就会返回未授权。这是最常见的坑，一定要仔细核对每个服务的配置文件。
• 检查请求是否正确携带Token
  登录成功后，网关会返回JWT Token，前端得在后续请求的Authorization头里带上Bearer {token}。你可以用Postman或者浏览器开发者工具看看请求头，确认这个头有没有正确传过去。另外，还要确认网关有没有把这个头转发给Web API——可以去Web API的日志里看请求头里有没有Authorization，如果没有，可能是网关的路由配置没设置转发这个头。
• 检查微服务的安全配置
  看看Web API的SecurityConfiguration里的规则，有没有允许网关的IP/域名作为可信客户端？JHipster默认会配置CORS和CSRF，要是这些规则阻止了网关的请求，也会出问题。另外，看看Web API的日志里有没有Token解析失败的具体信息，比如Token过期、签名无效，这些日志能帮你定位到具体原因。
• 确认服务间通信是否正常
  网关和微服务是不是都注册到了服务发现组件（比如Eureka、Consul）？网关能不能正确找到微服务？如果网关路由请求都失败了，也会导致认证问题，但这种情况一般会有路由错误的日志。另外，检查微服务application.yml里的jhipster.security.authorities-mapper配置，有没有正确映射网关传过来的角色信息。
• 验证Token的有效性和格式
  可以用JWT解析工具（比如jwt.io）解析一下Token，看看exp字段是不是过期了，签名是不是正确。如果是网关生成的Token但微服务解析失败，基本还是密钥不一致的问题。

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