OAuth2.0与1.0的对比与实例化描述分享

最新推荐文章于 2024-08-21 21:06:14 发布

weixin_30735391

最新推荐文章于 2024-08-21 21:06:14 发布

阅读量112

点赞数

原文链接：http://www.cnblogs.com/llw1996/p/11351298.html

版权

前言：云计算引出了大量的开放平台，各种第三方应用建立在开放平台之上，出于安全性的要求便出现了oauth协议，2007年发布了Oauth1.0协议，2.0的草案与2011年发布。

定义：OAuth： OAuth（开放授权）是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。

1、2.0的用户授权过程（过程可参考流程图）

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

　　（Client指第三方应用，Resource Owner指用户，Authorization Server是我们的授权服务器，Resource Server是API服务器。）

2、1.0的用户授权过程

客户端到授权服务器请求一个授权令牌(Request Token&Secret)
引导用户到授权服务器请求授权
用访问令牌到授权服务器换取访问令牌(Access Token&Secret)
用访问令牌去访问得到授权的资源

3、两者的对比：

　　OAuth1.0协议每个Token都有一个加密，2.0则不需要。这样来看1.0似乎更加安全，但是2.0要求使用https协议，安全性也更高一筹。

　　OAuth2.0充分考虑了客户端的各种子态，因而提供了多种途径获取访问令牌

　　　 a)授权码

b)客户端私有证书

c)资源拥有者密码证书

d)刷新令牌

e)断言证书

　　OAuth1.0只有一个用户授权流程。

　　 OAuth2.0较1.0相比，整个授权验证流程更简单更安全，也是未来最主要的用户身份验证和授权方式。

OAuth 2.0协议

协议的参与者

OAuth的参与者至少有以下四个：

RO(Resource Owner)：资源所有者，对资源具有授权能力的人。其实来讲就是用户，如上文的小明。
RS(Resource Server)：资源服务器，它存储资源，并处理对资源的访问请求。如上文的新浪微博资源服务器。
Client：第三方应用，它获取RO的授权后就可以访问RO的资源。如上文的第三方客户端。
AS(Authorization Server)：授权服务器，它认证RO的身份，为RO提供授权审批流程，并最终颁发授权令牌(Access Token)。AS和RS的功能可以由同一个服务器来提供。

简单的来讲就是用户、第三方客户端、服务器。这个服务器有两个工作：授权和提供资源。

OAuth的思路

OAuth在Client和RS之间设置了一层授权层。Client不能直接登录RS，只能利用令牌来登录授权层，而且这个令牌有权限范围和有效期。

时序图

基本流程：
1、 用户打开 第三方客户端（后面简称 客户端）， 客户端引导 用户去授权。
2、 用户同意授权给 客户端，也就是点击了同意授权的按钮，之后 客户端会拿到 授权证据。这里用户如何批准是关键，后面会讲到。
3、 客户端向 服务器请求 访问令牌(Access Token)，同时出示前面的步骤拿到的 授权证据。
4、 服务器通过认证后，向 客户端返回 访问令牌。
5、 客户端携带 访问令牌去访问 服务器上的资源。
6、 服务器验证令牌的有效期和真伪，验证通过后才能提供服务。

有两个关键的东西，一个是用户同意授权的授权证据，一个是用授权证据进一步请求拿到的访问令牌。

客户端的授权

上面讲到用户给客户端授权这一步是关键。客户端必须得到用户的授权才能获得令牌。Auth2.0定义了四种授权方式：

授权码模式
简化模式
密码模式
客户端模式

授权码模式

授权码模式是功能最完整、流程最严密的授权模式。其特点是通过Client的后台服务器与AS进行互动

基本流程：
1、客户端初始化协议的执行流程，通过HTTP 302来重定向用户代理到服务器。这里的用户代理基本上就是指浏览器。客户端申请认证的URI包含以下参数：

response_type：授权类型，此处的值固定为“code”(必选)
client_id：客户端的ID(必选)
redirect_uri：重定向URI(可选)
scope：申请的权限范围(可选)
state：客户端的当前状态，可指定任意值，认证RS会原封不动地返回这个值

2、服务器认证用户身份证，并提供页面供用户决定是否批准或拒绝客户端的此次请求。
3、若请求被批准，服务器使用步骤(1)中客户端提供的redirect_url重定向用户代理到指定页面。redirect_uri必须包含authorization_code，也就是我们前面所说的比较重要的授权证据。以及步骤(1)中Client提供的state。若请求被拒绝，AS将通过redirect_uri返回相应的错误信息。

code：授权码(必选)。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI是一一对应的关系。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

4、客户端拿authorization_code去访问服务器以交换所需的access_token，也就是前面所说的访问令牌。客户端请求信息中应包含用于认证客户端身份所需的认证数据，以及上一步请求authorization_code时所用的redirect_uri。

grant_type：授权模式，此处的值固定位“authorization_code”(必选)
code：上一步获取的授权码(必选)
redirect_uri：重定向URI，必须与步骤(1)中的该参数值保持一致(必选)
client_id：客户端ID(必选)

5、服务器收到authorization_code时需要验证客户端的身份，并验证收到的redirect_uri与步骤(3)请求authorization_code时所用的redirect_uri相匹配。如果验证通过，AS将返回access_token以及refresh_token。