OAuth2.0的一些疑问

本文不介绍OAuth，只是记录我对OAuth的一些疑问，对OAuth的学习，建议移步的阮一峰的网络日志-OAuth篇。另外下面OAuth指的都是2.0版本

1. 授权码(code)不担心暴露么？

不担心。该码有效期通常为10分钟，并且与客户端ID和重定向URI，是一一对应关系。另外授权码只能用一次，第二次使用会让使用该授权码获取的token失效，所以攻击者最多会让你出现登录意外失败，但无法获取你的数据

2. 图示OAuth完整流程

app和web的流程是一样的
也可以直接跟第三方平台交互获取token，取决于你们后端是否支持

3. 每次第三方登录，都需要重新走第二步的全部流程么？

假设用户已经获得授权，则下次登录时只需要验证access_token是否有效，无效则重新获取授权，有效则无需重新获得授权。

4. OAuth 2.0 CSRF攻击

正常的授权流程如下

1. 李四登录A网站，并跳转OAuth提供者B，B授权后将重定向到www.AAAA.com?code=xxxxxxx
2. A拿到code后想B请求token，A拿到token后向B请求李四在B上的个人信息，比如unionid
3. A在拿到unionid后会将李四在A网站上的uid进行绑定，从而实现李四在B上的账号可以登录A网站

CSRF的流程

1. 李四登录A网站，并跳转OAuth提供者B，B授权后将重定向到www.AAAA.com?code=xxxxxxx
2. 李四拿到这个Code之后不继续想B请求token，而是想办法诱导张三访问www.AAAA.com?code=xxxxxxx
3. 此时A就拿着李四的code去请求token，并获取李四的unionid
4. 在进行绑定时就是将李四B账号与张三A账号进行绑定
5. 最后李四就可以利用自己的B账号登录张三的A账号，进行为所欲为的操作
6. 备注：因为code的时效性，这种攻击需要被攻击者在code有效期内完成

解决方案

1. 在第一步传重定向地址的同时传一个state
2. 在授权成功进行重定向是B也会将state传给重定向地址www.AAAA.com?code=xxxxxxx&state=wwwwww
3. 在A用code向B获取token前对state做验证，验证不通过就判定是异常请求

state参数值需要具备下面几个特性：

1. 不可预测性：足够的随机，使得攻击者难以猜到正确的参数值
2. 关联性：state参数值和当前用户会话（user session）是相互关联的
3. 唯一性：每个用户，甚至每次请求生成的state参数值都是唯一的
4. 时效性：state参数一旦被使用则立即失效

4. OAuth1.0和OAuth2.0区别

2.0授权过程

1. 引导用户到授权服务器，请求用户授权，用户授权后返回 授权码(Authorization Code)
2. 客户端由授权码到授权服务器换取访问令牌(access token)
3. 用访问令牌去访问得到授权的资源

1.0授权过程

1. 客户端到授权服务器请求一个授权令牌(request token&secret)
2. 引导用户到授权服务器请求授权
3. 用授权令牌到授权服务器换取访问令牌(access token&secret)
4. 用访问令牌去访问得到授权的资源

安全性

1. 1.0的数据传输安全是基于签名，2.0是基于https
2. 1.0没有对重定向地址做任何验证也没有做签名，1.0a紧急修复让重定向地址参与签名。2.0取消签名，但授权方会对重定向地址进行校验(开发者会向授权方提交域名)

疑问

1. 1.0中即使重定向地址被修改，最多造成用户无法正常完成授权，攻击者在有授权令牌没有appid和appSecret的情况下也做不了什么事情啊，但为什么有些地方说可以攻击方还是可以等到到被攻击者的账号。