OAuth令牌如何传递回浏览器？相关认证机制疑问

1. 先搞懂 OAuth 里的「Client」和「Server」到底是谁 #

别把浏览器当成OAuth角色里的Client，这里的角色定义是：

• Client（客户端）：指你的Web应用后端服务（或者桌面APP、移动端APP）——它是主动向第三方认证服务器申请授权的主体，需要提前在认证服务器注册拿到Client ID和Client Secret。
• Server（服务器）：分两类：
  • 认证服务器：负责处理用户登录、授权操作，发放授权凭证（比如授权码、令牌）的第三方服务（比如GitHub、Google的OAuth服务）。
  • 资源服务器：存储用户数据的服务，你需要用OAuth令牌才能访问它的API（比如Google Drive、GitHub用户信息接口）。

浏览器只是用户和你的Web应用交互的前端载体，不属于OAuth的官方角色范畴。

2. 认证成功后重定向的令牌获取流程 #

整个流程是后端偷偷完成令牌交换，浏览器只负责跳转和携带会话凭证：

1. 用户在浏览器点击「用GitHub登录」，浏览器跳转至认证服务器的登录授权页（这一步是帮你的Web后端发起授权请求）。
2. 用户完成登录并确认授权后，认证服务器会重定向回你预先配置的回调地址（比如你的Web应用的/auth/callback），同时在URL参数里附带一个临时的code（授权码）。
3. 浏览器自动请求这个回调端点，你的Web后端拿到code后，在后端发起POST请求到认证服务器（这个请求浏览器完全看不到），用code+自己的Client ID/Secret交换真正的Access Token（通常还有Refresh Token）。
4. 后端拿到OAuth令牌后，不会直接返回给浏览器——而是生成自己的会话凭证（比如Session ID或者JWT），通过Cookie或响应体返回给浏览器。后续浏览器访问你的服务时，只需要携带这个会话凭证即可。

3. 关于浏览器请求回调端点和令牌存储的疑问 #

• 浏览器不会每次需要认证都请求回调端点：回调端点只在用户首次授权（或授权过期后重新授权）时被触发一次，用来完成授权码换令牌的操作。
• 正确的令牌存储方式：你的Web服务器会把拿到的OAuth Access Token/Refresh Token存在自己的存储系统里（比如数据库、Redis），并和用户的会话绑定。之后用户通过浏览器访问你的服务时，只用携带你的Web服务器生成的会话凭证，你的后端再用存储的OAuth令牌去和认证/资源服务器通信，不用重复走OAuth授权流程。

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