浅谈OAuth 和 OpenID 相关技术

/ Annabelle
目录
关于Token

Token 即使是在计算机领域中也有不同的定义，这里我们说的token，是指访问资源的凭据。例如当你调用 Google API 时，需要带上有效 token 来表明你请求的合法性。这是 Google 给你的，这代表 Google 给你的授权使得你有能力访问 API背后的资源。

请求 API 时携带 token 的方式也有很多种，通过 HTTP Header 或者 url 参数或者 google 提供的类库都可以：

SSO (Single sign-on)

通常公司内部会有非常多的平台供大家使用，比如人力资源，代码管理，日志监控，预算申请等等。如果每一个平台都实现自己的用户体系的话无疑是巨大的浪费，所以公司内部会有一套 公用的用户体系，用户只要登陆之后，就能够 访问所有的系统。这就是 单点登录。

SSO 是一类 解决方案的统称，而在具体的实施方面，我们有两种策略可供选择：

  • SAML 2.0
  • OAuth 2.0

接下来我们区别这 两种授权方式有什么不同。但是在描述 不同的策略之前，我们先叙述几个 共有的特性，并且相当重要的概念。

Authentication VS Authorization
  • Authentication: 身份鉴别，以下简称认证。认证的作用在于认可你能够访问系统，用于鉴别访问者是否是合法用户；
  • Authorization: 资源访问授权。 授权用于决定你有访问哪些资源的权限。

大多数人不会区分这两者的区别，因为站在用户的立场上。作为系统的设计者来说，这两者是有差别的，这是不同的两个工作职责。

我们可以只需要认证功能，而不需要授权功能，甚至不需要自己实现认证功能。而借助 Google 的认证系统，即用户可以用 Google 的账号进行登陆。

Authorization Server/Identity Provider(IdP)

把负责认证的服务称为 AuthorizationServer 或者 IdentityProvider，以下简称 IDP。

Service Provider(SP)/Resource Server

把负责提供资源（API 调用）的服务称为 ResourceServer 或者 ServiceProvider，以下简称 SP。

OAuth 2.0

  1. 用户通过客户端（可以是浏览器也可以是手机应用）想要访问 SP 上的资源，但是 SP 告诉用户需要进行认证，将用户重定向至 IDP。
  2. IDP 向用户询问 SP 是否可以访问用户信息。如果用户同意，IDP 向客户端返回 authorization code。
  3. 客户端拿到 authorization code 向 IDP 交换 access token，并拿着 access token 向 SP 请求资源。
  4. SP 接受到请求之后，拿着附带的 token 向 IDP 验证用户的身份。确认身份无误后，SP 向客户端发放相关资源。

但以上的 SSO 流程体现不出 OAuth 的本意。OAuth 的本意是一个应用允许另一个应用在用户授权的情况下访问自己的数据。

OAuth 的设计本意更倾向于授权而非认证（当然授权用户信息就间接实现了认证），虽然 Google 的 OAuth 2.0 API 同时支持授权和认证。所以你在使用 Facebook 或者 Gmail 账号登陆第三方站点时，会出现授权对话框，告诉你第三方站点可以访问你的哪些信息，需要征得你的同意。

在上面 SSO 的 OAuth 流程中涉及三方角色: SP, IDP 以及 Client。但在实际工作中 Client 可以是不存在的，例如你编写了一个后端程序定时的通过 Google API 从 Youtube 拉取最新的节目数据，那么你的后端程序需要得到 Youtube 的 OAuth 授权即可

OpenID VS OAuth

OpenID 和 OAuth 很像。但本质上来说它们是截然不同的两个东西：

  • OpenID: 只用于身份认证（Authentication），允许你以同一个账户在多个网站登陆。它仅仅是为你的合法身份背书，当你以 Facebook 账号登陆某个站点之后，该站点无权访问你的在 Facebook 上的数据。
  • OAuth: 用于授权（Authorisation），允许被授权方访问授权方的用户数据。
Refresh Token

这样的处理是为了职责的分离：

  • refresh token: 负责身份认证；
  • access token: 负责请求资源。