永久免费自助建网站,北京大学廉政建设研究中心网站,广州网站制作实力乐云seo,张店网站建设哪家好背景
为什么需要OAuth授权呢?
最典型的应用场景就是第三方登录了, 我们开发了一个网站希望用户可以QQ登录, 但是怎么能拿到用户的 QQ 信息呢? 用户将 账号密码告诉我们当然可以, 但是这样有如下隐患:
我们拿到了用户的密码, 这样很不安全. 而且任意一个应用被黑, 所有相关…背景
为什么需要OAuth授权呢?
最典型的应用场景就是第三方登录了, 我们开发了一个网站希望用户可以QQ登录, 但是怎么能拿到用户的 QQ 信息呢? 用户将 账号密码告诉我们当然可以, 但是这样有如下隐患:
我们拿到了用户的密码, 这样很不安全. 而且任意一个应用被黑, 所有相关站点均受影响QQ 需要支持密码登录, 但是单纯密码登录并不安全. 因此进而影响 QQ 的安全问题我们拿到密码之后, 就相当于拥有了用户的所有信息, 这样无法进行权限限制 可能只是希望授权用户名和头像, 但是连着好友列表一起交代出去了 用户一旦修改密码, 所有之前授权过的应用全部失效
基于以上原因, 就需要有这样一套机制:
不基于密码的授权授权存在时间限制, 并且随时可以收回权限收回单个应用的权限, 不会对其他已授权的应用造成任何影响可以仅授予个别权限, 而不是所有
没错, OAuth就是为了解决这个问题而提出来的.
介绍
OAuth是什么呢? 在RFC 文档中是这样介绍的. OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. 写的比较官方哈, 简单说, 就是授权他人以拥有临时访问资源的权限.
那么, OAuth1.0是如何实现这样的机制呢?
实现
在介绍其实现之前, 需要先来了解OAuth中的几个概念.
角色 Consumer 消费者, 既需要访问资源的应用ServiceProvider 服务提供者, 既提供资源的服务器User 用户
依旧使用我们上面的例子, 我们的博客网站需要接入 QQ 登录. 在这里, 博客网站就是其中的Consumer, 而 QQ 服务器就是ServiceProvider了. 为了方便立即, 下面均称为 博客网站 QQ服务器. 我们获取授权的流程大致如下图: 对其中的各个流程进行介绍
流程
在请求之前, 博客网站需要到 QQ 服务器 进行注册, 并获得如下标识:
consumer_key: 网站标识符consumer_secret: 网站使用的私钥
1. 获取 request_token
网站向QQ 服务器申请一个临时凭据, 用来在本次授权过程中进行校验.
携带参数
oauth_consumer_keyoauth_signature_method: 签名使用的生成方法oauth_signature: 本次请求的签名, 使用consumer_secret生成oauth_timestamp 时间戳, 用于对本次请求进行校验oauth_callback 回调链接, 用于在用户授权之后回调通知消费者oauth_nonce 随机字符串 此参数用来防止重放攻击, 即别人拿到请求链接再次请求因此, 服务提供者会对其进行验证是否处理过
返回数据
request_token: 此 token 仅用作后面授权中校验使用, 以及对本次授权进行标识request_secret: 用于本次授权的后续请求进行加密, 使用在第5步
2. 重定向到服务器授权页面
将页面重定向到 QQ 服务器 的授权页面.
携带参数
request_token: 用来向 QQ 服务器标识本次授权
3. 用户在 QQ 服务器完成授权操作
用户在 QQ 服务器的授权页面进行登录并授权
4. 回调函数通知授权成功
用户授权成功后, QQ 服务器将链接重定向到 第一步指定的 回调链接. 并在回调链接上附带结果:
request_token: 用来对本次授权进行标识. 毕竟博客网站收到回调时, 需要知道是哪个用户授权成功了.verifier: 在下一步获取 access_token 中检验使用. 具体作用在下一步说明.
5. 授权成功后获取 access_token access_secret
此时用户已经同意了权限的授予, 博客网站可以到 QQ 服务器获取用户的授权码了.
返回数据
access_tokenaccess_token_secret
用户后续就使用这两个授权信息到 QQ 服务器请求资源.
access_token_secret作用
这里有个小疑问, 既然有了access_token, 又为什么需要access_token_secret呢?
因为访问数据使用HTTP协议, 对数据的传输过程没有安全保障. 在后续访问资源时, 若仅使用consumer_secret对请求进行签名, 若consumer_secret泄露了, 那么攻击者只要获得用户的access_token就拥有了其权限. 而access_token又需要在访问是携带在参数中对权限进行标识. 故而十分危险.
在生成签名时, 额外加上access_token_secret进行签名, 而access_token_secret不会在后续访问中传递, 每个用户又都是不同的, 因此即使consumer_secret泄露了, 攻击者也无法获得所有用户的权限.
携带参数
consumer_keyrequest_tokensignature_methodtimestampnonceverifiersignature
verifier作用
那么, 这里的oauth_verifier有必要么? 其实它是为了防止 session固话攻击, 感兴趣的可以搜索OAuth Session Fixation Attack查看具体内容. 这里简单介绍一下.
假设, 有一个攻击者监控了你的网络请求, 因为使用了HTTP协议, 明文信息也没什么秘密. 那么攻击者就可以在第一步时获得本次授权的request_token. 同时攻击者又通过暴力破解或其他方法, 获得了consumer_secret.
此时, 若没有verifier参数, 本次请求的所有参数攻击者均可以构造. 若攻击者频繁访问本次请求, 又恰好在用户授权完成和网站回调的间隙发起了合法访问, 就会成功获得用户的access_token.
通过添加随机的verifier可以使得本次请求不可预测.
问题
对于OAuth1.0实现的一些问题:
使用了HTTP协议, 安全性较低使用HTTP协议, 没有对服务提供者的真实性进行校验对非web应用(如安卓)支持很不友好. (也有通过 PIN 码实现的, 这里不展开介绍了)签名过程复杂. 需要同时使用consumer_secretaccess_token_secret进行签名. (也是因为使用HTTP协议)
这些问题在OAuth2.0得到了解决, 详情查看下一篇文章: OAuth2.0介绍
