OAuth 2.0: Concepts

20th August 2020 at 2:19pm
OAuth 2.0

设计理念

根据 wikipedia

开放授权(OAuth)是一个开放标准,允许用户让第三方应用访问该用户在某一网站上存储的私密的资源(如照片,视频,联系人列表),而无需将用户名和密码提供给第三方应用。

Mastering OAuth 2.0 写道:

OAuth 2.0 is a protocol that allows distinct parties to share information and resources in a secure and reliable manner.

解决的问题

OAuth 2.0 解决两个问题:

  • 联合身份(federated identity):允许用户使用另外一个服务的帐号登录此服务。比如用微信登录京东,用 Google 登录 Medium。这使得用户只需要维护一个帐号
  • 授权(delegated authority):授权一个服务以用户的身份去访问它在另外一个服务中的信息。比如你可以授权 LinkedIn 帐户访问你的 Google 联系人这种非公开的信息

假如在有 OAuth 2 之前,应用 GoodApp 想访问你的 Facebook 联系人列表,那它不得不向你询问你的 Facebook 帐户的用户名密码。这样引起的问题是:

  • 你给了 GoodApp 对你的 Facebook 帐户做任何事情的能力
  • GoodApp 会储存你的密码,并且它可能由于被黑导致你的密码泄露
  • 除非你修改你的 Facebook 密码,否则你没有办法收回这份授权

有了 OAuth 2 之后:

  • 你不再需要给 GoodApp 你的 Facebook 密码,而是通过 Facebook 授权给一个 token 到 GoodApp
  • 你可以限定 GoodApp 能访问你的哪些 Facebook 数据,比如只能读取好友列表
  • 你可以随时在 Facebook 这边收回对 GoodApp 的授权

更通俗的理解是:用户的密码是全权限的 token,token 是只有部分权限的密码

Components

理解 OAuth 的具体流程之前,先理解下它的几个组成部分:

  • Resource Owner:资源的所有者,一般指用户;比如某个用户它拥有它的 Facebook 好友列表(资源)
  • User Agent:用户的设备;比如浏览器、手机 native app
  • Client:想要使用用户的资源的客户端或服务;比如上述例子中的 GoodApp,想获得用户的 Facebook 好友列表
  • Authorization Server (AS):向 client 发放 access token,使得 client 可以访问具体资源服务器
  • Resource Server (RS):即资源所在的服务。client 通过 AS 发放的 access token,在此处可以使用实际的资源

Authorization server 及 resource server 可能实现在同个域名也可能分开,但是它们背后的服务商一般是一样的,比如同样属于 Facebook。

Flow

OAuth 2 提供了 4 种授权类型(authorization grant type):

  • Authorization code grant
  • Implicit grant
  • Resource owner password credentials grant
  • Client credentials grant

第一种 authorization code grant 是最常见的,其次是 implicit grant。剩余的两种不做讨论。对于前两种方式,核心的点是:

  • Client 预先在 AS 上注册了它的服务;AS 会给 client 一个 client ID 来标识它
  • Client 最终要通过 AS 获得一个 access token,才能 RS;而 AS 需要用户允许才给 access token

Authorization code grant

流程如下:

绝大多数互联网产品都采用这种流程,比如 Google、Twitter、GitHub。看这个 GitHub 的 例子 来深入理解这套流程。

这里演示一个基于 GitHub 的 OAuth 应用,在获取用户授权后显示用户所有仓库信息的例子。GitHub 的 官方文档 对这个过程有详细地说明。我做了一个 YouTube 视频来描述这个过程:

代码及预编译好的多平台可执行文件在 这里

仅当存在 client 且它可以安全地保存信息时(包含 client secret 及 access token),才应该使用 authorization code grant 方式。假如它无法安全保存信息:

  • client secret 被盗会导致黑客可以以此应用身份欺骗用户
  • access token 被盗则黑客可以以用户身份做任何操作

怎样界定有无安全存放信息的条件?

  • 如果你的 client 是纯 JS 应用,没有后台服务器,那它被认定为不满足。因为 JS 的 Storage API 和 cookie 都是不安全的,可以被外部读取的
  • 如果你的 client 包含一个后台服务,一般被认为是满足的。后台可以通过保护数据库和使用各种加密方式来保证数据安全
  • 如果你是在使用某个手机客户端(比如 GitHub 第三方客户端来访问 GitHub),这个客户端如果用了系统提供的安全能力(比如 Android),则可以认定为是满足的

如果不满足的话,需要走 implicit grant type 流程。

Implicit grant type

流程如下:

对比于 authorization code grant,这个流程的特点在于少了 client application,因此也没有哪一环可以安全地存放用户的 access token,所以 access token 直接给到了 user agent,并且一般会设置一个比较短的(如 1 小时)的有效时间。User agent 拿到 access token 后直接使用。

这种流程在互联网服务中比较少见,用户体验也会相对较差。