首页 » OAuth

oauth

OAuth是一种安全协议,允许第三方访问网站资源而不用共享资源站点的密码。2007年11月,OAuth1.0发布,很快成为工业标准,2010年4月,OAuth1.0发布为RFC 5849。OAuth2.0是全新的协议,并不向后兼容之前的版本。但OAuth2.0保留了前版协议的整体架构,以及前版协议建立的方法。IETF OAuth WG负责OAuth协议。

OAuth的典型使用场景如:社交网站使用你的Google地址簿发现你的好友;Facebook帐号登录第三方网站等。

OAuth协议介绍

在正式接触OAuth协议前,我们先思考下,这个系统应该怎样运作。我们的目的是分享用户资源。系统涉及三个主要用户:用户资源拥有者(如Facebook、Google、淘宝这些站点)、开发者、用户。基于OAuth协议的一个应用:第三方ID登录。例如开发者拥有一个网站,允许用户用自己的Facebook账户登录。对开发者而言,降低了用户注册门槛;对用户而言,不用记忆不同网站的密码;对Facebook而言,扩大了自己的影响力。这是个三赢的局面。

为了达成这个三赢局面,我们站在开发者的角度看,开发者应该做些什么。开发者需要到Facebook注册一个应用帐号,填写一坨资料,表明自己的身份。完成注册后,获取一个身份识别码(ID),开发者的程序与Facebook的系统交互,都通过这个ID进行。开发者继而提供一个登录页面,让用户用Facebook账户登录。这时用户就要授权开发者的网站,可以访问自己在Facebook的信息(如Email等)。如果用户已登录Facebook,直接授权即可;如果用户没有登录,则需先登录Facebook再进行授权。用户授权完成后,Facebook会给开发者的程序一个凭证(访问令牌),表明开发者的程序可以通过这个访问令牌来获取用户资料。访问令牌有一定的有效期,也有一定的访问范围,如果过期或超出访问范围,就需要用户重新授权。

以上就是OAuth协议的大致思想。那篇著名的OAuth 2.0介绍一文中这样形象的比喻OAuth用来做什么

Many luxury cars(高级轿车) come with a valet key(供停车场服务员使用的车钥匙). It is a special key you give the parking attendant(停车场服务员) and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.

维基百科上对valet key(供停车场服务员使用的车钥匙)的说明:

Some cars come with an additional key known as a valet key that starts the ignition(点火开关) and opens the driver's side door, but prevents the valet from gaining access to valuables that are located in the trunk or the glove box.

在OAuth协议中,Facebook授予的访问令牌就相当于高级轿车的valet key。

OAuth 工作流程

认证和授权(Authentication & Authorization)

例如 Berlinix.com 为用户提供 Facebook ID 登录方式,当用户登录时,有以下流程:

  1. 用户访问 Berlinix.com ,用 Facebook ID 登录。
  2. Berlinix.com 向 FB 请求一个临时令牌(Request Token)。
  3. FB 验证 Berlinix.com 的身份,并授予一个临时令牌。
  4. Berlinix.com 获取临时令牌后,将用户引导至 FB 的授权页面并请求用户授权。
  5. 用户授权。(如果用户已登录 FB,可以直接授权;否则,用户先用 FB 的帐号密码登录 FB,再进行授权)
  6. 授权成功,返回 Berlinix.com
  7. Berlinix.com 根据临时令牌从 FB 获取访问令牌(Access Token)
  8. FB 根据临时令牌和用户授权,授予 Berlinix.com 访问令牌
  9. Berlinix.com 通过访问令牌访问用户在 FB 上的个人信息。

来自RFC的流程图例:

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

这里涉及到4个角色:

  1. Client,即第三方网站
  2. Resource Owner,资源拥有者,即用户
  3. Authorization Server,授权服务器,负责给第三方网站下发访问令牌(Access Token)
  4. Resource Server,资源服务器,即存储着用户信息的服务器,需要访问令牌才能获取资源。

访问令牌的作用域

Access Token Scope

访问令牌用来访问用户的受保护数据。不同数据处在不同的域/范围(scope)中。

参考

一份OAuth2.0的简单介绍
Google OAuth2.0 API

分享

0