OAuth 2.0 基础

本篇文章主要讲述OAuth2.0的一些基础知识,并不涉及具体的实现。在下一篇文章中,我会具体的说一下客户端和服务端的实现
作为应用程序开发人员,相信您可能已经听说过OAuth 2.0这个术语,甚至在你的系统中使用过oauth2.0。 OAuth 2.0已经被世界各地的网络服务和软件公司广泛采用,并且是这些公司互动和共享信息的方式的组成部分。 简单的说:

OAuth 2.0是一种允许不同方面以安全可靠的方式共享信息和资源的协议

这是OAuth 2.0协议的主要宗旨,我们将在这篇文章简单的总结一下oAuth2.0,并且通过一个实际的例子来完整的演示oAuth2.0开发工作。

OAuth 1.0简单描述

OAuth 1.0在2007年被设计和批准。然而它被批评为过于复杂,也存在不精确的规范的问题,导致了一些不安全的实现。 所有这些问题导致OAuth 1.0的采用不佳,最终导致了OAuth 2.0的设计和创建。 OAuth 2.0是OAuth 1.0的继承者。
同样重要的是要注意,OAuth 2.0不向后兼容OAuth 1.0,因此OAuth 2.0应用程序无法与OAuth 1.0服务提供商集成。

授权 VS 认证

  • 授权(Authentication) 授权是给某人或者某个角色赋予某些权限
  • 认证(Authorization) 认证是确认某些人或者某个角色具有某些权限

OAuth 2.0的常见应用

  • 允许用户使用其他帐户登录应用程序。 比如可以使用QQ账号登录新浪微博。这种的也成为federated identity
  • 允许某个服务代表用户访问另一个服务的资源。例如,Adobe服务需要访问您的Facebook照片,这个时候需要你授权容许这种操作,这被称为delegated authority

联合身份(Federated identity)

联合身份是身份管理中的一个重要概念。 它指的是一个服务提供商允许用户使用他们的另一个服务提供商的身份认证的概念。 例如,比如可以使用QQ账号登录新浪微博。 在这个例子中,用户只需要维护一个QQ用户帐户,他们就可以通过这个QQ账号登录新浪微博,网易云音乐等服务。也就是通常的第三方登录。这个时候, 在这种情况下,Facebook本身,加上Foursquare和Amazon。 他们不需要在Foursquare或Amazon上创建个人帐户,因此不需要维护三个单独的密码。 在这个意义上,用户在这些网站上的身份是联合的,因为它们被作为一个,也就是QQ账号
严格来说,OAuth 2.0协议实际上是授权协议而不是认证协议。 因此,仅OAuth 2.0无法提供联合身份。 然而,当以某种方式使用并且与其他协议一起使用时,OAuth 2.0可以提供联合认证,联合身份验证是联合身份系统的关键组件。
一般比较常见的方法是OAuth 2.0和OpenID结合起来。
为了说清楚如何使用OAuth2.0如何解决资源共享问题,我们首先来简单的说一下在OAuth2.0之前,资源共享问题是怎么解决的,然后在介绍使用OAuth2.0解决这个问题。我们在此假定有下面的一个场景:
假设有一个服务GoodApp,希望给你推荐一些GoodApp的朋友,但是为了给你推荐这些GoodApp上的朋友,他需要访问你在Facebook上的朋友列表。

不使用OAuth2.0解决资源共享问题

在OAuth2.0之前,GoodApp需要你提供Facebook的用户名和密码,然后GoodAPP拿着用户名和密码代替你访问Facebook获取你在Facebook上的朋友列表。可以看出,这种解决方案需要你告诉GoodApp你Facebook的用户名和密码,这明显有安全隐患。这个交互过程使用图来表示的话:

这种解决方案的问题的缺点有:

  • GoodAPP可以拿着你的Facebook用户名和密码做任何事情,比如删除你发的照片,文章。
  • GoodApp有可能会保存你的用户名和密码,一旦GoodApp被拖库的话,你的用户名和密码就可能发生泄漏
  • 你并没有办法取消对GoodApp的授权,有可能GoodApp提供了注销账号的功能,但是谁知道他是否会删除之前保存的用户名和密码

使用OAuth2.0解决资源共享问题

我们这次使用OAuth 2.0协议。 在这种情况下,您可以通过登录Facebook并批准该请求来授予GoodApp访问你Facebook朋友的权限。一旦请求被批准,GoodApp就可以代表您从Facebook获取您的朋友列表。

这种解决办法的优点:

  • 你不需要告诉GoodAPP你的Facebook的账号和密码
  • 可以撤销GoodAPP对Facebook的访问权限:OAuth 2.0提供了撤销访问权限的功能。

授权类型(grant types)

OAuth 2.0通过使用不同的工作流程以各种方式支持信息交换。 在OAuth 2.0术语中,这些术语称为授权类型(grant types)。 OAuth 2.0有两种主要的授权类型, 他们是:

  • 授权代码授权(Authorization code grant)
  • 隐性授权(Implicit grant)

授权代码授权通常被称为服务器端工作流,而隐式授权通常被称为客户端工作流。

OAuth 2.0授权框架
OAuth 2.0规范实际上描述了两种额外的授权类型:资源所有者密码凭据授权(resource owner password credentials grant)和客户端凭证授权(client credentials grant)以及创建自己的定制资源授权的功能来满足您的需求。然而,上面提到的那种隐含的授权和授权代码授权是最常用的两种方式,因此本文只讨论这两种

隐性授权(Implicit grant)

还以上面的GoodAPP的例子来说明吧。在隐性授权中,GoodApp本身并不存储任何的认证信息或者token,因此这种交互流程特别简单:

从上面的图可以看出,当用户点击同意授权以后:

  • Facebook给了客户端GoodAPP一个一个可以访问Facebook用户列表的Key
  • GoodAPP拿着Key去访问Facebook提供的请求朋友列表的接口
  • Facebook会校验这个key,如果成功的话就会给GoodAPP返回朋友列表

上面的key在OAuth2.0的术语中叫做access token.

Access token VS bearer token

Access token是一个字符串值,表示在特定时间段内对受保护资源的访问。 你也可以听到一个叫做bearer token的东西。 bearer token只是一种Access token。 还有其他类型的访问令牌,但bearer token是最常用的令牌类型。
它被称为bearer标记,因为令牌的承载保持使用它所必需的全部。 不需要额外的信息。 这个意思是说,任何有这个bearer token的人,GoodApp都可以使用它,Facebook会很乐意返回你的朋友列表,没有问题。就如同一把钥匙,无论谁拿着这把钥匙都可以打开门

什么时候使用隐性授权(Implicit grant)

隐式授权类型是为不受信任的客户端而设计的。这些客户端往往是纯粹的基于浏览器的应用程序,如HTML、JavaScript应用程序或Flash应用程序,这些应用程序不需要长期访问用户的数据。以下是应用客户端流程的客户端应用程序的一些示例:

  • iPhone上的Safari中运行的HTML / JavaScript应用程序
  • 在Android设备上运行Chrome的Flash应用程序
  • 在没有后端服务器的情况下运行的本机iOS应用程序
  • 在桌面上的Firefox中运行的HTML / JavaScript应用程序

隐性授权(Implicit grant)的优缺点

优点

两个字,简单。因为不需要经过后端程序,所有的工作都发生在前端。

缺点

安全性比较低,因为access token很容易被别人拿到。而且这种实现方式,一般都是有效期比较短的,需要经常重新认证。
作为应用程序开发人员,如果您使用隐式授权类型在不信任客户端上开发应用程序,则最好将请求限制为只读权限。
这样,如果有人窃取用户的密钥,他们只能读取用户的数据,而不是修改它。 数据可能仍然是机密的,
但至少您最大限度地减少了在泄漏情况下可能发生的潜在损害。

授权代码授权(Authorization code grant)

授权代码授权一般适用于那种有后端程序的场景,比隐试授权稍微复杂一些,具体的完整交互流程图如下:

从上面的交互图可以看出,Facebook首先会给GoodApp一个tag,而不是直接给access token,然后GoodApp后端程序拿着这个tag再次请求Facebook的接口,获取access token,Facebook会验证这个tag,如果验证成功的话,那么GoodApp就可以获取到朋友列表。
需要注意的是,上面的交互流程中的tag属于消耗品,只能使用一次,不能重复拿着tag去请求key。在OAuth2.0的术语中,上面的tag被称为authorization code
授权代码授权(Authorization code grant)与隐试授权的流程(即隐式授权流程)之间的重要区别在于access token永远不会发送到浏览器!访问令牌直接在Facebook和GoodApp服务器的后端程序之间交换。因此access token的泄漏或拦截机会显着降低。

优缺点

优点

对比隐试授权来说更加的安全,因为access token仅仅在双方的后端程序之间流通,同时客户端也有能力来存储access token以及一些必要的信息,这样就可以达到长期使用甚至离线使用用户数据的目的。

缺点

缺点主要是复杂一些,因为需要后端程序的参与,而且交互流程较多一些,工作量稍微大一些。

本文版权归作者所有,禁止一切形式的转载,复制等操作
赞赏

微信赞赏支付宝赞赏

发表评论

电子邮件地址不会被公开。 必填项已用*标注