OAuth2.0协议

OAuth 2.0 的四种方式

Oauth2.0详解及安全使用

微信网页开发-网页授权

具体而言，网页授权流程分为四步：
1、引导用户进入授权页面同意授权，获取code
2、通过code换取网页授权access_token（与基础支持中的access_token不同）
3、如果需要，开发者可以刷新网页授权access_token，避免过期
4、通过网页授权access_token和openid获取用户基本信息（支持UnionID机制）

OAuth2.0的安全解析

风险1:redirect_url 回调域名欺骗

服务端必须验证clientid注册的应用与redirect_url是对应的，否则redirect_url会被伪造成第三方欺诈域名，直接导致服务器返回Code被泄露；

服务器生成的临时Code必须是一次有效，客户端使用一次后立即失效并且有效期很短，一般推荐30s有效期，由于Code是通过redirect_url浏览器回调传输容易被截取，可以保证临时Code被客户端正常消费后不会被再次使用；

风险2:redirect_url XSS跨域攻击

比如构造一个认证请求，redirect_uri = http://app.com/test?callback= 服务器端需要对redirect_url进行检查禁止特殊字符输入，并且对redirect_url进行全匹配，不做模糊匹配可以杜绝XSS攻击；

风险3:State 防止CSRF

认证请求url中state参数是最容易被忽略的，大部分IDP不会强制要求客户端使用state参数；

客户端每次请求生成唯一字符串在请求中放到state参数中，服务端认证成功返回Code会带上state参数，客户端验证state是否是自己生成的唯一串，可以确定这次请求是有客户端真实发出的，不是黑客伪造的请求；

风险4:Access_Token泄露

由于Access_Token是通过http协议从服务器端传输给客户端，为了防止旁路监听泄露Access_Token，服务器必须提供https来保证传输通道的安全性（TSL的要求）；

客户端获取Access_Token，应该在后台与服务端交互获取Access_Token，不允许Access_Token传给前端直接使用；

需要保证Access_Token信息的不可猜测行，以防止被猜测得到；

风险5:令牌有效性漏洞

维持refresh_token和第三方应用的绑定，刷新失效机制的设计不允许长期有效的token存在；