欢迎光临
专注android技术,聚焦行业精粹,我们一直在努力

OAuth 2.0 Authorization Framework

背景

我们经常会遇到这样的场景,在应用的登录等敏感操作过程中会提示需要QQ,微信,Google,Facebook等第三方应用授权的界面。如下图所示:

这些授权登录是怎么实现的呢?它们是如何确保授权操作的安全的呢?我们这篇文章就介绍一下OAuth2.0,这个框架就解决了这样场景中的问题。

 

1、OAuth2.0介绍

在传统的client-server授权模型中,客户端通过使用资源所有者凭证向服务器进行身份验证来请求服务器上的访问受限资源(受保护资源)。

传统的client-server授权模型

问题分析:

  • 第三方应用程序需要存储资源所有者的凭据供将来使用,通常是密码明文。
  • 尽管密码固有的安全弱点,服务器仍需要支持密码认证。
  • 第三方应用程序获得对资源所有者的受保护资源的过度访问和超出范围的访问,使资源所有者无法限制持续时间或访问有限的资源子集。
  • 资源所有者不能在不撤销对所有第三方的访问权限的情况下仅对单个人撤销第三方的访问权限,并且必须通过更改第三方密码来实现。
  • 任何第三方应用程序的妥协都会导致最终用户的密码以及该密码保护的所有数据的安全。

OAuth通过引入授权层并将客户端的角色与资源所有者的角色分开来解决这些问题。 在OAuth中,客户端请求访问由资源所有者控制并由资源服务器托管的资源,并发出与资源所有者不同的凭据集。

客户端不是使用资源所有者的凭证来访问受保护的资源,而是获取访问令牌(access token) – 一个表示特定范围,生存时间和其他访问属性的字符串。 授权服务器在获得资源所有者的同意后向第三方客户端颁发访问令牌(access token)。 客户端使用访问令牌(access token)访问资源服务器托管的受保护资源。

本规范旨在与HTTP([RFC2616])一起使用。

OAuth 1.0协议([RFC5849])是小型特别社区努力的结果。 此标准跟踪规范基于OAuth 1.0部署体验,以及从更广泛的IETF社区收集的其他用例和扩展性需求。 OAuth 2.0协议不向后兼容OAuth 1.0。 这两个版本可能共存于网络上,实现可能会选择支持这两种版本。 但是,本规范的目的是针对新的实现来支持本文档中指定的OAuth 2.0,并且OAuth 1.0仅用于支持现有的部署。 OAuth 2.0协议与OAuth 1.0协议共享很少的实现细节。 熟悉OAuth 1.0的实现者不应该假设其内部的结构和细节的情况下学习此文档。

 

1.1、角色

OAuth定义了四个角色:

资源所有者
一个能够授权访问受保护资源的实体。当资源所有者是一个人时,它被称为最终用户。

资源服务器
承载受保护资源的服务器,能够接受并响应使用访问令牌(access token)来访问受保护的资源请求。

客户端
一个应用程序通过使用授权信息向资源所有者的受保护资源发起请求。术语“客户端”并不意味着任何特定的实现特征(例如,无论该应用是在服务器,台式机还是其他设备上执行)。

授权服务器
在成功通过资源所有者认证并获得授权后,该服务器向客户端发放访问令牌(access token)。

授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以是与资源服务器相同的服务器,或者也可以是一个独立的实体。一个授权服务器可以为多个资源服务器发布访问令牌(access token)

 

1.2、协议流程

 

 

 

图2:qq OAuth2.0举例

 

图1中所示的抽象OAuth 2.0流程描述了四个角色之间的交互,图2中举了映射到qq实际使用场景中的OAuth2.0交互流程,包含以下步骤:

  • 1) 客户端请求来自资源所有者的授权。授权请求可以直接给资源所有者(如图2中直接展示给用户),也或者间接地通过授权服务器作为中介。
  • 2) 客户端接收授权许可,这是一种代表资源所有者授权的凭证。
  • 3) 客户端通过向授权服务器进行身份验证来请求访问令牌(access token)。
  • 4) 授权服务器对客户端进行身份验证并验证授权,如果有效,则颁发访问令牌(access token)。
  • 5) 客户端提供访问令牌(access token)认证,并从资源服务器请求受保护的资源
  • 6) 资源服务器验证访问令牌(access token),并且如果有效,则为该请求提供服务。

客户从资源所有者获得授权许可的另一种推荐方法是使用授权服务器作为中介(即授权码模式),如图3所示。

图3: (A), (B), and (C) 步骤的标线通过用户代理拆分成2部分

它解决的问题场景:

以获取QQ用户信息资源为例,我们自己的App作为图中的Client端,是无法向用户获取授权的,这时我们需要一个对于用户可信度高的用户代理来做这件事情(例如:QQ App),所以我们经常会看到第三方App(即Client)会拉起QQ去授权(User-Agent)。拿到QQ App返回的授权码(auth code)后,再附上自己App(Client)的信息(例如:client_id),到授权服务器换取access token。不过实际QQ授权不是这种授权码模式,而是下面会介绍的简化模式

它的具体步骤如下:

(A)用户访问客户端,后者将前者导向认证服务器。
(B)用户选择是否给予客户端授权。
(C)假设用户给予授权,认证服务器将用户导向客户端事先指定的”重定向URI”(redirection URI),同时附上一个授权码(auth code)。
(D)客户端收到授权码(auth code),附上早先的”重定向URI”,向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。
(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。

 

1.3、refresh token

刷新令牌是用于获取访问令牌(access token)的凭证。刷新令牌(refresh token)由授权服务器发布给客户端,用于在当前访问令牌变得无效或到期时获得新的访问令牌(access token),或者获得具有相同或更小范围的额外访问令牌(access token)。

根据授权服务器的判断,发布刷新令牌(refresh token)是可选的。 如果授权服务器发出刷新令牌(refresh token),则在发布访问令牌(access token)时包括它(即图1中的步骤(D))。

刷新令牌(refresh token)是表示资源所有者授予客户端授权的字符串。 该字符串通常对客户端不透明。 令牌表示用于检索授权信息的标识符。 与访问令牌(access token)不同,刷新令牌(refresh token)仅用于授权服务器,绝不会发送到资源服务器。

图4:刷新一个过期的Access Token

图4所示的流程包括以下步骤:

A) 客户端通过向授权服务器进行身份验证并提交授权许可来请求访问令牌(access token)。

B) 授权服务器对客户端进行身份验证并验证授权,如果有效,则发出访问令牌(access token)和刷新令牌(refresh token)。

C) 客户端通过提交访问令牌(access token)向资源服务器发出受保护的资源请求。

D) 资源服务器验证访问令牌(access token),并且如果有效,则为该请求提供服务。

E) 重复步骤(C)和(D),直到访问令牌到期。 如果客户端知道访问令牌已过期,则跳至步骤(G); 否则,它会发出另一个受保护资源请求。

F) 由于访问令牌无效,资源服务器将返回无效令牌错误。

G) 客户端通过向授权服务器进行身份验证并提交刷新令牌(refresh token)来请求新的访问令牌(access token)。客户端身份验证要求基于客户端类型和授权服务器策略。

H) 授权服务器对客户端进行身份验证并验证刷新令牌(refresh token),如果有效,则发出新的访问令牌(access token)(以及可选的新刷新令牌(refresh token))。

 

1.4、授权模式

客户端必须得到用户的授权(authorization grant),才能获得令牌(access token)。OAuth 2.0定义了四种授权方式。

  • 授权码模式(authorization code)
  • 简化模式(implicit)
  • 密码模式(resource owner password credentials)
  • 客户端模式(client credentials)

 

1.4.1、授权码模式(authorization code)

上面介绍协议流程中已经介绍了授权码模式,授权码授权类型用于获取访问令牌(access token)和刷新令牌(refresh token),并针对安全性较高的客户端进行了优化。由于这是基于重定向的流程,因此客户端必须能够与资源所有者的用户代理(通常是Web浏览器)进行交互,并且能够从授权服务器接收传入请求(通过重定向)。这个是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与”服务提供商”的认证服务器进行互动。如下图中所示的“用户不可见”部分的交互流程是在客户端的后台服务器中完成的.

授权码模式

 

1.4.2、简化模式(implicit)

这种模式在国内使用的场景就非常多了,如常见的QQ,微博登录等。它不通过第三方应用程序的后台服务器,直接在浏览器中向认证服务器申请令牌(access token),跳过了”授权码”这个步骤(上面授权码模式省去了“用户不可见”这个在后台服务器处理的步骤,直接在浏览器(用户代理)中完成),因此得名。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。

简化模式

QQ登录使用的就是简化模式的OAuth2.0流程登录,具体参考QQ的简化模式接入步骤,下面的截图是QQ登录的OAuth2.0简化模式的接入过程,client需要带上client_id和回调地址请求QQ的User Agent地址,最终User Agent授权成功后会把access token通过你传入的回调地址返回给client。

qq简化模式授权

 

OAuth2.0的剩余两种模式:密码模式和客户端模式由于在实际的使用场景中很少接触到,这里不做介绍,详细可以参考OAuth2.0官方文档

 

2、OpenId介绍

在QQ登录,微博等国内常见的第三方登录授权中我们经常看到openid的概念,那么openid到底是什么?它和OAuth2.0又有什么不同呢?

2.1、什么是openId

OpenID允许你使用一个已经存在的账号去在多个网站上面登录,而不需要创建新的密码。

你可以选择将OpenID关联的信息和你访问的网站共享,例如名字或者email地址。有了OpenID你可以控制具体哪些信息你需要和你访问的网站共享。

有了OpenID你的密码只会给到你信任的身份提供者,然后该提供商会向您访问的网站确认您的身份。除了您的提供商之外,任何网站都不会看到您的密码。所以你不必担心一个肆无忌惮或不安全的网站会危及你的身份。

OpenID正迅速在网络上获得采用,拥有超过10亿启用OpenID的用户帐户和超过50,000个接受OpenID登录的网站。几家大型组织发布或接受OpenID,包括谷歌,Facebook,雅虎,微软,美国在线,MySpace,西尔斯,环球音乐集团,法国电信,Novell,Sun,意大利电信等等。

 

2.2、OpenID和OAuth2.0的不同

简单的说 OAuth关注的是authorization(授权);而OpenID侧重的是authentication(认证)

下面详细比较两者的区别:

  1. OpenID的目的是创建一个联合的认证,也就是说,让第三方为您验证您的用户,通过使用它们已经有的账号。联合这个词在这里很重要,因为OpenID的重点在于可以使用任何提供者(除白名单外)。您无需事先选择或与供应商协商交易,以允许用户使用他们拥有的任何其他账户。OAuth的出现是为了消除用户与第三方应用程序共享密码的需求。它实际上是为了解决OpenID问题而开始的。如果您的网站支持OpenID,则无法使用HTTP基本凭据(用户名和密码)来提供API,因为用户在您的网站上没有密码。问题在于,将OpenID分别用于身份验证和用于授权的OAuth是两种协议都可以完成许多相同的事情。它们都提供了不同实现所需的一组不同的功能,但基本上它们是可以互换的。它们的核心是,两种协议都是断言验证方法(OpenID仅限于’我是谁’断言,而OAuth提供了’访问令牌’,可以通过API交换任何支持的断言)。
  2. 特性这两种协议都为网站在其他地方重定向用户提供了一种方式,并返回可验证的断言。OpenID提供身份断言,而OAuth则以访问令牌(access token)的形式更通用,然后可用于“询问OAuth提供者的问题”。但是,它们都支持不同的功能:OpenID – OpenID最重要的功能就是它的”发现”过程。OpenID不需要提前对每个您想要使用的提供商在代码中写死。使用”发现”,用户可以选择任何他们想要认证的第三方提供商。这个发现功能还导致了大部分OpenID的问题,因为它的实现方式是使用HTTP URI这种大多数Web用户无法明白的标识符。OAuth – OAuth最重要的功能是访问令牌(access token),它提供了一种持久的方式来发起额外的请求。与OpenID不同,OAuth不会以身份认证结束,但会提供访问令牌(access token)以访问由同一第三方服务提供的其他资源。但是,由于OAuth不支持”发现”,它需要预先选择并硬编码您需要使用的提供商。此外,OAuth没有身份概念,因此使用它来登录意味着要么添加一个自定义参数(如Twitter所做的),要么进行另一个API调用以获取当前“登录”用户。
  3. 从技术实现来看,两种协议都使用了一种通用的结构——使用重定向来获取用户的授权。在OAuth中用户授权来访问受保护的资源,而在OpenID中用户授权来访问它们的身份。每个协议都有不同的计算签名的方式来验证请求或响应的真实性,并且每个协议都有不同的注册要求。
下面的图展示了OpenID基于OAuth2.0的简单模式完成身份认证的过程:
赞(1) 打赏
未经允许不得转载:花花鞋 » OAuth 2.0 Authorization Framework
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

国内精品Android技术社区

联系我们

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏