REST API设计：传递Discord access_token用自定义Header还是Authorization头？

毫无疑问，Authorization: Bearer <access_token>是更符合HTTP规范和行业最佳实践的方案，原因如下：

1. 遵循HTTP标准
   Bearer令牌认证是RFC 6750定义的标准方案，专门用于传递OAuth2访问令牌。所有主流HTTP客户端、框架和安全工具都默认支持这种格式，不会出现自定义头被代理、WAF拦截或解析异常的问题。

2. 场景完全契合
   你可能误解了“传统授权场景”——用户通过Discord OAuth2获取的access token，本质就是用来向你的API证明身份的凭证，这完全符合Bearer令牌的设计初衷：第三方颁发的令牌，用于访问受保护的资源。

3. FastAPI完全支持
   不存在“不符合FastAPI流程”的问题，你可以通过自定义依赖轻松获取并验证Bearer令牌，示例代码如下：

   from fastapi import FastAPI, Request, HTTPException, Depends
   
   app = FastAPI()
   
   async def validate_discord_token(request: Request):
       auth_header = request.headers.get("Authorization")
       if not auth_header or not auth_header.startswith("Bearer "):
           raise HTTPException(status_code=401, detail="请提供有效的Discord访问令牌")
       return auth_header.split("Bearer ")[1]
   
   @app.post("/execute-dashboard-action")
   async def execute_action(discord_token: str = Depends(validate_discord_token)):
       # 调用Discord API验证令牌权限
       # 执行对应操作
       return {"status": "success", "message": "操作已完成"}
   

关于自定义头的问题 #

使用Discord-Access-Token这类自定义头虽然实现简单，但存在明显缺陷：

• 不符合HTTP规范，其他开发者接手时需要额外学习你的自定义规则
• 部分代理服务器或安全设备可能会过滤非标准HTTP头，导致请求失败
• 无法利用现有框架的令牌解析、验证工具，需要重复造轮子

额外安全建议 #

• 强制使用HTTPS：所有传递令牌的请求必须通过HTTPS发送，防止令牌在传输过程中被窃听
• 合理存储令牌：前端存储时优先使用HttpOnly、Secure属性的Cookie，避免存在localStorage中被XSS攻击窃取
• 处理令牌过期：Discord的access token有过期时间，要实现刷新令牌逻辑，避免用户频繁重新登录

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