OAuth/OIDC技术：SPA应用UI组件可见性管理方案探讨

答案是不合理，原因如下：

• Access Token的设计初衷是供资源API验证请求合法性，它的受众（aud声明）是API服务，而非客户端UI。客户端依赖其Claims做UI逻辑，违背了OAuth的职责分离原则。
• 为UI需求往Access Token中添加与资源无关的Claims，会导致Token体积膨胀，且混淆了API权限与UI体验逻辑的边界，后续维护成本高。
• 若未来Access Token改为不透明格式（很多安全场景会这么做），客户端将无法读取Claims，直接导致UI逻辑崩溃。

方案1：使用OIDC的UserInfo端点 #

OIDC扩展了OAuth2，专门设计了UserInfo端点供客户端获取用户身份与权限信息，完全契合UI体验的需求：

• 在授权服务器（STS）中配置UserInfo端点，返回UI所需的专属声明（比如ui_roles、allowed_menus），与Access Token中的API权限声明彻底分离。
• 客户端通过ID Token获取访问UserInfo端点的权限，流程符合标准规范，无需额外开发新服务。
• 适用场景：UI权限逻辑相对简单，可通过用户身份、全局角色等静态信息确定。

方案2：搭建专属UI权限API端点 #

如果UI权限与业务逻辑深度绑定（比如需根据用户所属项目、业务状态动态计算组件可见性），推荐单独开发一个UI权限API：

• 该API接收客户端的Access Token，验证身份后返回当前用户的UI组件可见性配置（如JSON格式的菜单列表、按钮状态集合）。
• 权限逻辑集中在后端管理，可灵活调整，且与API服务的访问权限完全隔离，避免耦合。
• 适用场景：复杂业务场景下的动态UI权限控制。

方案3：利用ID Token的声明（限简单场景） #

ID Token的受众是客户端本身，可存储与用户身份直接相关的基础信息：

• 若UI仅需基于用户角色、用户类型等简单信息控制可见性，可将这些声明添加到ID Token中，客户端直接读取使用。
• 注意：不要在ID Token中添加过多业务权限信息，避免Token体积过大或泄露敏感内容。

无论采用哪种方案，UI层面的组件可见性控制仅为用户体验优化，必须确保资源API自身的权限校验独立且严格——任何操作请求都要经过API的权限验证，不能依赖UI的隐藏/禁用逻辑作为安全屏障。

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