授权码流使用规范咨询：React前端访问微服务如何避免暴露Access Token

当前流程的规范问题 #

你的实现流程确实不符合授权码流的规范，核心问题集中在以下几点：

• 你将Access Token发送到前端并在前端存储、使用，违反了《Getting Started with OAuth 2.0》中「OAuth令牌不能泄露至用户可访问的浏览器中」的核心要求——前端浏览器存在XSS攻击风险，令牌一旦被窃取，攻击者可直接冒充用户调用API。
• 前端完成Access Token的刷新操作，会导致Refresh Token也暴露在前端环境中，进一步放大安全风险，Refresh Token本应仅在后端安全环境中使用。
• 你的架构把前端作为了实际的OAuth客户端，但书中明确授权码流的适用场景是「OAuth客户端为Web应用服务器」，前端属于公共客户端，不适合直接持有敏感令牌。

实现前端访问微服务不暴露Access Token的方案 #

核心思路是让后端服务作为OAuth客户端，令牌全程在后端安全环境中流转，前端仅持有会话标识而非真实令牌，具体流程如下：

1. 前端生成state参数，引导用户跳转到授权服务器的授权端点，回调地址需指向你的后端服务（如网关或专门的认证服务），而非前端页面。
2. 后端服务接收授权服务器返回的授权码和state，验证state合法性后，用授权码换取Access Token和Refresh Token，将这两个令牌安全存储（例如关联用户会话存入Redis，设置合理过期时间）。
3. 后端服务向前端返回一个带有HttpOnly、Secure、SameSite属性的Cookie作为会话标识，该Cookie无法被前端JS读取，可有效防范XSS攻击。
4. 前端调用微服务时，直接携带此Cookie请求后端网关；网关先验证Cookie对应的会话有效性，再取出后端存储的Access Token，代表用户调用目标微服务，最后将微服务的响应结果返回给前端。
5. Access Token过期时，由后端自动使用Refresh Token换取新的Access Token，前端完全感知不到令牌的存在和刷新过程。

这种调整既符合授权码流的规范（客户端为后端服务器、令牌不暴露到浏览器），又能保证API调用的可追溯性，同时大幅提升了认证流程的安全性。

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