java oauth 1.0a_OAuth 流程与发展总结 (1.0 => 1.0a => 2.0)

最新推荐文章于 2024-09-01 07:02:32 发布

章兮苒

最新推荐文章于 2024-09-01 07:02:32 发布

阅读量407

点赞数

文章标签： java oauth 1.0a

本文链接：https://blog.csdn.net/weixin_36286774/article/details/114546115

版权

OAuth 流程与发展 (1.0 => 1.0a => 2.0)

概述

概述: 开放授权协议

作用: 允许第三方应用访问服务提供方中注册的终端用户的部分资源

下面是官方描述: [OAuth描述] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

参与者:

Client (Consumer) => 第三方应用

Resource Owner(User) => 用户

Resource Server(Service Provider) => 资源服务提供方(OAuth2.0将服务提供方拆分为两部分)

Authorization Server(Service Provider) => 授权服务提供方(OAuth2.0将服务提供方拆分为两部分)

OpenID (WHO) 和 OAuth (WHAT)

=> OpenID 更加关注 '我是谁' 的问题

=> OAuth 更加关注 '我能获得哪些权限的问题'

OAuth1.0 流程图

接口

(步骤 A) Consumer申请Request Token(/oauth/1.0/request_token)：

oauth_consumer_key

oauth_signature_method

oauth_signature

oauth_timestamp

oauth_nonce

oauth_version

(步骤 B) Service Provider返回Request Token：

oauth_token

oauth_token_secret

(步骤 C) Consumer重定向User到Service Provider(/oauth/1.0/authorize)：

oauth_token

oauth_callback

(步骤 D) Service Provider在用户授权后重定向User到Consumer：

oauth_token

(步骤 E) Consumer申请Access Token(/oauth/1.0/access_token)：

oauth_consumer_key

oauth_token

oauth_signature_method

oauth_signature

oauth_timestamp

oauth_nonceoauth_version

(步骤 F) Service Provider返回Access Token：

oauth_token

oauth_token_secret

OAuth1.0 漏洞

两种Token，分别是Request Token和Access Token，其中Request Token又涉及两种状态，分别是未授权和已授权。

攻击者会先申请攻击者自己的Request Token，然后诱使用户授权这个攻击者的Request Token，接着针对回调地址的使用，又存在以下几种攻击手段：

如果Service Provider没有限制回调地址(应用设置没有限定根域名一致)，那么攻击者可以把oauth_callback设置成成自己的URL。

如果Consumer不使用回调地址(桌面或手机程序)，而是通过User手动拷贝粘贴Request Token完成授权的话，那么只要攻击者在在User前面发起请求，就能拿到User的Access Token。

OAuth1.0 改进

步骤 B 传递 callback_url参数 (而不是获取已授权 request_token 步骤) Consumer申请Request Token时，必须传递oauth_callback, 让callback参与签名, 避免攻击者假冒callback。

验证完未授权 request_token 返回新的参数 oauth_verifier 验证完成后会返回验证码(oauth_verifier)在没有callback的时候, 服务提供方显示给用户，然后用户可以在第三方应用的设备上输入，标示自己已经授权(和未授权的用户分开)，然后第三方应用必须加上该验证码去获取

OAuth1.0a 流程图

OAuth2.0 流程

OAuth 2.0定义了四种授权方式。

授权码模式(authorization code)(本文只讲解该授权方式)

简化模式(implicit)

密码模式(resource owner password credentials)

客户端模式(client credentials)

接口

(步骤 A) Client 向Authorization Server发出申请(/oauth/2.0/authorize)：

response_type = code client_id redirect_uri scope state

(步骤 B) Authorization Server 在Resource Owner授权后给Client返回

code state

(步骤 C) Client向Authorization Server发出申请(/oauth/2.0/token)：

grant_type = authorization_code code client_id client_secrect redirect_uri

(步骤 E) Server在Resource Owner授权后给Client返回Access Token：

access_token token_type expires_in refresh_token

关于 state 参数

[RFC 对state参数的解释]

The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URIscheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization).

我们假设出现下面的场景:

(1)用户甲到第三方网站A登录后，到了绑定页面。此时还没绑定微博。

(2)绑定页面提供一个按钮：“绑定微博”(地址a：http://aaa.com/index.php?m=us...)

(3)用户甲点击地址a，程序生成如下地址b：

https://api.weibo.com/oauth2/...【9999999】&redirect_uri=【http://aaa.comindex.php】&response_type=【code】

(4)用户甲浏览器定向到地址b，授权该应用。

(5)授权服务器根据传递的redirect_uri参数，组合认证参数code生成地址c：

http://aaa.comindex.php&code=【809ui0asduve】

(6)用户甲浏览器返回到地址c,完成绑定

此时即使我们交换两个用户的地址c,则会出现绑定错误的情况,避免出现该情况的办法就是对state参数进行验证,来判断该state参数是否是该用户所对应的重定向地址

参考文献

结语