Keycloak UMA疑问：为何由客户端请求RPT令牌而非资源服务器？

1. 资源服务器能否直接与认证服务器交互获取RPT？ #

• 核心障碍是UMA的设计模型要求客户端作为用户的代理发起权限请求：RPT是绑定用户、客户端和资源权限的令牌，资源服务器没有用户的授权上下文（比如用户的主动授权意愿），且前端Angular属于公共客户端，无可用的密钥凭证，无法合法代表用户向认证服务器请求RPT。
• 从安全边界看，资源服务器直接交互需要持有客户端凭证或用户的refresh token，但前者不能暴露给后端，后者属于客户端的专属持有范围，资源服务器持有会破坏OAuth2/UMA的职责划分，增加令牌泄露风险。
• 多资源服务器场景下，客户端统一管理RPT可避免重复请求，而每个资源服务器各自维护与认证服务器的交互会导致状态分散，提升系统复杂度。

2. 已认证客户端的场景下，是否必须返回ticket？ #

• UMA规范的基础场景是客户端未携带认证信息，但扩展到“已认证但权限不足”的场景完全合理。当客户端携带access token访问资源时，资源服务器验证用户身份后，若发现当前access token不具备目标资源的细粒度权限，返回ticket让客户端换取RPT，是符合UMA“权限协商”核心逻辑的——本质是资源服务器告知客户端需要更精准的权限令牌。
• Keycloak的UMA实现本身支持这种流程，你的场景中返回ticket是规范的合理延伸，无需局限于基础场景的描述。

3. Spring资源服务器能否存储RPT？是否属于不良实践？ #

• 技术上可以实现存储，但通常属于不良实践：
  • RPT是用户与客户端绑定的令牌，资源服务器的无状态设计核心是不存储用户会话/令牌信息，存储RPT会引入状态，降低系统的可扩展性与容错性。
  • RPT有过期时间，且用户权限可能在认证服务器端被动态调整（比如管理员修改权限），资源服务器存储RPT会导致权限判断的一致性问题——缓存的RPT无法反映最新权限状态。
  • 正确的做法是客户端存储RPT并在过期前刷新，资源服务器每次收到RPT时，通过认证服务器的introspect接口验证令牌有效性及权限（或直接验证JWT格式RPT的签名），必要时可基于令牌指纹短期缓存验证结果，但不要存储RPT本身。

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