本文介绍一种安全可靠的方案：前端使用第三方oauth令牌（如google access token）完成身份认证后，后端验证其有效性并查询数据库中的用户角色，再签发一个由你完全控制的、含角色信息的自定义jwt；前端后续所有请求均携带该自定义jwt，确保角色数据不可篡改且服务端可信任。

本文介绍一种安全可靠的方案：前端使用第三方oauth令牌（如google access token）完成身份认证后，后端验证其有效性并查询数据库中的用户角色，再签发一个由你完全控制的、含角色信息的自定义jwt；前端后续所有请求均携带该自定义jwt，确保角色数据不可篡改且服务端可信任。

在基于第三方 OAuth（如 Google）的单页应用中，一个常见误区是直接将第三方 Access Token 用于前后端全部鉴权逻辑。但正如问题所述，Google 的 Access Token 不包含 roles 等业务级声明，且前端无法安全依赖后端响应中返回的角色字段——因为一旦攻击者拦截或篡改 /api/user/roles 接口的响应，就可能伪造高权限角色（如 "ROLE_ADMIN"），导致前端错误渲染管理界面，造成越权风险。

✅ 正确做法是：将第三方登录仅作为“身份断言”环节，真正的会话凭证（含角色）必须由你的后端签发、签名并全程管控。

✅ 推荐架构流程（安全闭环）

1. 前端：用户点击“用 Google 登录” → 调用 Google OAuth 流程 → 获取 access_token（仅用于首次认证）

2. 前端 → 后端：将该 access_token 发送到你自己的 /api/auth/login 接口（不暴露给资源服务器直接使用）

3. 后端验证 & 角色注入：

   • 使用 Google Public Keys（JWKS）验证 JWT 签名与有效期；
   • 解析 sub（用户唯一标识）或 email 查询本地数据库（如 users 表）获取该用户的角色列表（如 ["ROLE_USER", "ROLE_EDITOR"]）；
   • 使用你自己的密钥（如 HS512 或 RS256）签发一个全新 JWT，明确嵌入 authorities（Spring Security 兼容格式）：

     {
       "sub": "1234567890",
       "email": "user@example.com",
       "authorities": ["ROLE_USER", "ROLE_EDITOR"],
       "exp": 1735689600,
       "iat": 1735686000
     }

4. 后端返回该自定义 JWT 给前端（建议通过 HttpOnly + Secure Cookie，或前端安全存储于内存/sessionStorage）

5. 后续所有 API 请求：前端在 Authorization: Bearer <your-custom-jwt> 中携带该令牌

6. 后端资源保护：配置 Spring Security 验证你自己的 JWT（而非 Google Token）：

   @Configuration
   @EnableWebSecurity
   public class SecurityConfig {
       @Bean
       public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
           http
               .authorizeHttpRequests(auth -> auth
                   .requestMatchers("/api/public/**").permitAll()
                   .requestMatchers("/api/admin/**").hasRole("ADMIN")
                   .anyRequest().authenticated()
               )
               .oauth2ResourceServer(oauth2 -> oauth2
                   .jwt(jwt -> jwt
                       .jwtAuthenticationConverter(customJwtAuthConverter()) // 映射 authorities
                   )
               );
           return http.build();
       }
   
       @Bean
       public JwtAuthenticationConverter customJwtAuthConverter() {
           JwtGrantedAuthoritiesConverter authoritiesConverter = new JwtGrantedAuthoritiesConverter();
           authoritiesConverter.setAuthorityPrefix(""); // 不加 ROLE_ 前缀（若 payload 中已是 "ROLE_USER"）
           authoritiesConverter.setAuthoritiesClaimName("authorities");
   
           JwtAuthenticationConverter converter = new JwtAuthenticationConverter();
           converter.setJwtGrantedAuthoritiesConverter(authoritiesConverter);
           return converter;
       }
   }

⚠️ 关键注意事项

• ❌ 切勿在前端解析或信任任意后端返回的“角色数组” —— 即使接口受保护，HTTP 响应仍可被浏览器插件或中间人篡改；
• ✅ 所有权限判断必须在服务端完成：@PreAuthorize("hasRole('ADMIN')") 或 SecurityContext.getAuthentication().getAuthorities() 是唯一可信依据；
• ? 自定义 JWT 必须使用强密钥签名（推荐 RS256 + 私钥签发 / 公钥校验），禁用 none 算法；
• ? 前端角色展示（如菜单/按钮显隐）应仅作为 UX 优化，最终权限控制必须由后端 API 层强制校验；
• ? 若需保留原始 Google Token（例如调用 Google Drive API），可将其作为额外 claim 存入自定义 JWT（如 "google_token": "ya29..."），但绝不用于你的系统鉴权。

通过该模式，你既复用了 Google 的身份认证能力，又完全掌控了授权上下文（roles）、会话生命周期与安全边界，真正实现“身份（Identity）与权限（Authority）分离”，兼顾安全性与可维护性。