赞
踩
OAuth是一个开放的标准,在移动、web平台能提供一种安全地API授权,使第三方应用不需要密码账号通过授权的方式就可以进行登录。
要解决的问题:打破传统的账号密码登录登录方式,不管是对于用户还是应用提供商,都能安全保障账号数据不被泄露。
1 请求request code 和 access token过程中,得到的客户端错误响应码:
1.1 HTTP 400 Bad Request 请求出错
1.1.1 Unsupported parameter 不支持的参数
1.1.2 Unsupported signature method 不支持的签名方法
1.1.3 Missing required parameter 少传必需的参数
1.1.4 Duplicated OAuth Protocol Parameter 重复的OAuth协议参数
1.2 HTTP 401 Unauthorized 未授权
1.2.1 Invalid Consumer Key 无效的Consumer key
1.2.2 Invalid / expired Token 无效的token
1.2.3 Invalid signature 无效的签名
1.2.4 Invalid / used nonce 无效的随机数
| 解释 | 优点和缺点 |
|
---|---|---|---|
OAuth2.0 | 主要有4种授权模式,最全面的是授权码模式。见下图 | 改进1:去掉签名,改用SSL(HTTPS)确保安全性。 改进2:所有的token不再有对应的secret存在,签名过程简洁,这也直接导致OAuth2.0不兼容老版本。 改进3:能更好地支持不是基于浏览器的应用。 改进4:OAuth2.0的访问令牌是“短命的”,且有刷新令牌(OAuth1.0可以存储一年及以上)
|
|
OAuth1.0a | 1.向服务器端请求未授权的request token,入参: oauth_consumer_key oauth_signature_method oauth_signature oauth_timestamp oauth_nonce oauth_version oauth_callback 2.服务器返回未授权request token oauth_token oauth_token_secret oauth_callback_confirmed 3.传参未授权request token请求资源存储服务器的授权页 oauth_token 4.授权成功,返回授权后的request token oauth_token oauth_verifier oauth_consumer_key oauth_token oauth_signature_method oauth_signature oauth_timestamp oauth_nonce oauth_version oauth_verifier 6.返回access token与access token secret换取资源。 oauth_token oauth_token_secret | 总结:OAuth1.0a和OAuth1.0的过程看起来一样,但是改进了每一步骤里面的入参和返回值,仔细一看是不一样的。 具体改进1:将oauth_callback回调时机提前,参与签名过程。下一步将没办法伪造回调地址。 具体改进2:用户授权后,返回oauth_verifier,它会被用Consumer申请Access Token的过程中。攻击者无法猜测它的值。
缺点: 1.使用的是http协议 2.签名过程复杂而实用性不高。 |
|
OAuth1.0 | 1.客户端向资源服务器请求未授权Request Token,传入以下参数 oauth_consumer_key oauth_signature_method oauth_signature oauth_timestamp oauth_nonce oauth_version 2.服务器返回未授权Request Token和secret,返回参数如下: oauth_token oauth_token_secret 3.客户端入参oauth_token oauth_callback请求服务器,调起授权页面 oauth_token oauth_callback 4.等用户授权后,回到客户端,返回授权Request Token oauth_token 5.获取到授权Request Token,再向资源服务器换取票据accessToken,传入参数: oauth_consumer_key oauth_token oauth_signature_method oauth_signature oauth_timestamp oauth_nonce oauth_version 6.返回oauth_token oauth_token_secret
| 优点:步骤1是签名过程 缺点: 1.用的是http协议,申请RequestToken过程中,容易被攻击者调包。 2.攻击者调包后的目的就是伪造回调地址,拿到用户的accessToken。 那么OAuth1.0a的产生主要是为了修复以上的问题。 |
|
授权模式 | 步骤流程 | 备注 |
---|---|---|
授权码模式 | OAuth2授权流程主要分为4步: 1. 引导用户进入授权页面同意授权,获取code 2. 重定向第三方应用,通过code换取授权access_token 3. 如果需要,开发者可以通过refresh_token刷新授权access_token,避免过期 4. 通过授权access_token获取用户基本信息 场景:微信OAuth2.0,支持授权码模式。 | code有效期十分钟,且只能使用一次,服务器会根据code和有效期时间作对比,如果不是则授权失败。 access_token的有效期两个小时,过期后refresh_token刷新。 这种模式跟老版本最为贴近,相比其他模式复杂些,但更安全。适用于所有有Server端的应用,如Web站点、有Server端的手机客户端。
|
简化模式 | OAuth2授权流程主要分为3步: 1. 引导用户进入授权页面同意授权,获取授权access_token 2. 如果需要,开发者可以通过refresh_token刷新授权access_token,避免过期 3. 通过授权access_token获取用户基本信息 场景:QQ第三方登录 | 简化者模式一步到位获取到access_token,如何保证安全? 适用于所有无Server端配合的应用, |
密码模式 | OAuth2授权流程主要分为3步: 1.用户向客户端提供用户名和密码 2.客户端将用户名和密码发给认证服务器,向认证服务器请求令牌 3.认证服务器确认无误后,向客户端提供访问令牌。 | 这种模式适用于用户对应用程序高度信任的情况。 |
客户端模式 | OAuth2授权流程主要分为两步: 1.客户端发出HTTP请求,传参 grant_type scope 2.认证服务器向客户端发送令牌 access_token expires_in | 客户端模式应用于应用程序与授权服务器以及资源服务器进行互动。无机密传输。
|
1. 在授权码模式下,授权服务器先返回授权码code给第三方应用,第三方应用再利用授权码来换取access_token。为什么不直接返回access_token?
主要是为了安全考虑,在第三方应用http协议的情况下,容易被中间者攻击,很容易被中间者劫持到access_token。code的存在便是解决中间者攻击问题的。假如code被中间者拿到,不是一样也会拿到access_token吗?其实不是,code有效期十分钟且只能被使用一次,当攻击者拿到code请求授权服务器,第三方应用也拿code请求授权服务器,攻击者和第三方应用同时拿到access_token,授权服务器会因为code被使用两次,将本次access_token失效。
2.Implicit 就是直接获取的 access token,那它怎么处理中间人攻击?
QQ互联开放平台QQ登陆oauth授权接口可以劫持access_token
第三方应用和认证服务器等全程强制用https协议的情况下,redirect_url后面加上#
3.为什么授权模式为了避免CSRF攻击,可以在URL请求后面加个参数state,这是什么原理?
state参数能标记这是来自哪一个网站,state参数是攻击者拿不到的,因此可以避免CSRF攻击。
备注:
CSRF(Cross-site request forgery):跨站请求伪造,利用的是网站对网页浏览器的信任,攻击者主要做的就是欺骗用户浏览器,以用户的名义进行操作。
主要的防范措施:1.在http头部增加一个referer字段,这个字段就可以标记这是来自哪一个网站 。 2.服务器下发一个随机 Token,每次发起请求时将 Token 携带上,服务器验证 Token 是否有效。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。