如何在不调用Keycloak API的情况下安全验证OIDC令牌？

本地JWT验证的核心：签名防篡改机制 #

• JWT的签名由Keycloak用私钥生成，服务端通过Keycloak提供的公钥验证签名有效性。只要签名验证通过，就能确认令牌内容未被篡改，且确实由Keycloak颁发——毕竟私钥仅由Keycloak持有，第三方无法伪造合法签名。
• 公钥可从Keycloak的/.well-known/openid-configuration端点获取，服务端可本地缓存公钥并定期更新（比如每日/每周），无需每次请求都调用Keycloak。

伪造JWT的可能性：几乎为零（前提是严格执行签名验证） #

• 任何人都能生成JWT，但没有Keycloak的私钥，生成的令牌签名无法通过公钥校验。服务端只要把签名验证作为本地验证的核心步骤，伪造的令牌会直接被拒绝。
• 注意：绝对不能跳过签名验证只解码内容，这是致命漏洞。

用户存在性与状态校验的解决方案 #

本地验证确实无法实时同步Keycloak的用户状态（比如用户被删除、禁用，或令牌被主动撤销），可通过以下方式弥补：

• 缩短令牌过期时间：将access token的过期时间设为15-30分钟，即便令牌被盗或用户状态变更，风险窗口也极小。过期后用户需重新获取令牌，此时Keycloak会自动校验用户状态。
• 令牌撤销与黑名单机制：若需立即失效令牌（比如用户登出、权限变更），可维护一个令牌黑名单。服务端在验证签名后，额外检查令牌是否在黑名单中。黑名单可用Redis等缓存存储，设置与令牌过期时间一致的TTL，避免内存溢出。
• 按需调用Introspection端点：对高敏感接口，仍可选择调用Keycloak的introspection端点做实时校验，平衡性能与安全性。

你遗漏的关键环节：信任边界与生命周期管理 #

• 信任边界：服务端预先信任Keycloak的公钥，这是本地验证的基础。只要令牌是Keycloak用私钥签名的，就默认其内容可信——这是OAuth2/OIDC的核心信任模型。
• 令牌生命周期：本地验证的局限性需要通过合理的令牌过期策略、撤销机制来弥补，而非依赖实时的用户数据库校验。RPT的本地验证也基于此模型：Keycloak颁发RPT时已完成权限校验，服务端只需验证签名即可信任其中的权限信息。

澄清：Introspection与Userinfo的区别 #

• introspection API：用于校验令牌的有效性（是否过期、是否被撤销、用户是否有效），返回令牌状态信息，是实时校验的手段。
• userinfo API：用于获取用户额外信息（比如邮箱、昵称），不能用来验证令牌有效性——调用它的前提是已确认令牌合法。

内容的提问来源于stack exchange，提问作者Ansis Spruģevics