关于从auth server获取access key的安全问题及防范措施咨询

核心问题结论 #

第三方即便获取到携带authorization code的重定向URL，也无法正常获取到access key，你提到的同路由触发POST请求获取凭证的假设不成立，原因如下：

• 携带授权码的重定向URL首先命中的是客户端服务端的GET回调接口，不会直接调用authorization server的token兑换接口
• 兑换access key必须的client_secret是仅在客户端服务端和authorization server之间存储的机密值，不会暴露给任何前端或第三方，第三方无法拿到该参数完成token兑换请求
• 正规OAuth实现中，授权码和发起授权的用户、客户端身份是绑定的，就算第三方拿到授权码，也无法完成后续的兑换校验逻辑

风险防护措施 #

按照OAuth2.0标准实现以下防护规则，即可完全规避这类授权码劫持风险：

• 强制使用state参数校验：发起授权请求时生成随机、不可预测的state值，存储在用户侧带HttpOnly、Secure、SameSite属性的安全cookie中，authorization server回调时会原样返回该state，服务端回调接口必须先校验返回值和cookie中存储的state完全一致，不一致直接拒绝请求
• 授权码设置短有效期且仅可使用一次：authorization server侧需将授权码有效期设置为10分钟以内，且授权码只要被用于兑换过一次token就立即失效，即使泄露也没有可被利用的时间窗口
• 严格校验回调URI：在authorization server注册客户端时，必须固定完整的回调地址，不允许使用泛域名、路径通配符，authorization server下发授权码前会校验当前请求的回调地址和预先注册的完全一致，避免授权码被发送到恶意域名
• token兑换接口强制客户端身份校验：authorization server的/token接口必须要求请求方携带client_id和client_secret完成身份认证，推荐通过Authorization: Basic <base64(client_id:client_secret)>请求头传递校验参数，不允许将client_secret放在URL参数或公开位置传递，直接拒绝所有未通过身份校验的兑换请求
• 避免授权码日志泄露：禁止在前端日志、服务端访问日志中打印完整的重定向URL参数，全程使用HTTPS传输避免中间人截获URL内容

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