OAuth2学习笔记

2017-12-07

概念

OAuth 2.0 的角色定义

• Resource Owner - 可以授权別人去存取 Protected Resource 。如果这个角色是人类的话，则就是指使用者 (end-user)。
• Resource Server - 存放 Protected Resource 的服务器，可以根据 Access Token 来接受 Protected Resource 的请求。
• Client - 代表 Resource Owner 去存取 Protected Resource 的应用程序。 “Client” 一词并不指任何特定的实现方式（可以在 Server 上面跑、在一般电脑上跑、或是在其他的设备）。
• Authorization Server - 在认证过 Resource Owner 并且 Resource Owner 许可之后，核发 Access Token 的服务器。
  Authorization Server 和 Resource Server 的互动方式不在本 spec 的讨论范围。
  Authorization Server 跟 Resource Server 可以是同一台，也可以分开。单一台 Authorization Server 核发的 Access Token ，可以设计成能被多个 Resource Server 所接受。

Clients

在OAuth 2.0的 spec 里面，按保密能力 Clients 分成两类： confidential 和 public。

• confidential 能够保存密码的软件，例如Server上运行的软件
• public 不能保存密码的软件，例如在Client运行的软件、Browser等

EndPoints

在 OAuth 2.0 里面，Endpoints （数据传输端点）共有三种：

• Authorization Server 的 Authorization Endpoint
• Client 的 Redirection Endpoint
• Authorization Server 的 Token Endpoint

流程

Authorization Grant Code Flow

这个流程比较适合在Server端运行的程序使用，流程理解如下：

1. 用户（Resource Owner）打开浏览器访问受保护的网站
2. 网站返回302重定向到认证服务（Authorization Server）
3. 用户输入用户名密码认证后，从Authorization Server获取到Authorization Code，并将浏览器转回原网站
4. 原网站的服务端拿到Authorization Code后向Authorization Server获取Access Token

此流程完成可以避免浏览器端拿到Access Token，因Authorization Code是一次性的并时效最长只有10分钟，也就避免了盗用Authorization Code获取Access Token的情况。

Implicit Grant Flow

这个流程比较适合浏览器访问的Web应用，流程理解如下：

1. 用户（Resource Owner）打开浏览器访问受包含的网站
2. 网站返回302重定向到认证服务（Authorization Server）
3. 用户输入用户名密码认证后，从Authorization Server获取到Access Token，并将浏览器转回原网站
4. 原网站验证Access Token有效后即认为用户已经通过认证

此流程是专门为特定的 Public Client 来优化的，例如跑在 Browser 里面的应用程序。但也因此有外泄风险，例如：

• Resource Owner 可以看到 Access Token
• 其他可以存取 User-Agent 的应用程序，也可以看到 Access Token
• Access Token 传输时，会直接出现在 Redirection URI 里面，所以 Resource Owner 以及同一台设备的应用程序可以看到

因为要实施转址，所以 Client 要可以跟 Resource Owner 的 User-Agent (Browser) 互动，也要可以接收从 Authorization Server 来的 Redirection Request。（同 Authorization Code Grant Flow）

最后拿到的只有 Access Token ，不会拿到 Refresh Token （禁止核发 Refresh Token）。

Resource Owner Password Credentials Grant Flow

此流程简单的说就是 直接用Resource Owner 自己的账号密码密碼从Authorization Server 获取 Access Token 。这中流程只有在以下情况才能使用：

• Resource Owner 高度信赖 Client ，例如操作系统內建的应用程序（好比说 OS X 的 Twitter 整合）或是官方应用程序。
• 其他別的流程都不适用。

而就算 Client 可以直接拿到 Resource Owner 的账号密码，也只会使用一次，用來取得 Access Token 。Spec 里面定义的流程，会要求 Client 不存储账号密码，而是随后以长时效的 Access Token 或 Refresh Token 取代之。

Authorization Server 应该要特別小心开放这种流程，并且要在別的流程都行不通的时候才使用这种。

这种流程适用于可以取得 Resource Owner 账号密码的 Client （通常是通过一个輸入框）。也可以用来把以前的账号密码认证，迁移到 OAuth 认证。

最后拿到的除了 Access Token 之外，还会拿到 Refresh Token （Authorization Server 支持的话）。

Client Credentials Grant Flow

即 Client ID + Client Secret 。适用于运行在 Server 的没有用户参与的 Client 。

如果是以下情况的话，就可以使用这个流程：

• Client 自己就是 Resource Owner ，Client 取用的是自己拥有的 Protected Resources
• Client is requesting access to protected resources based on an authorization previously arranged with the authorization server. （这个我看不懂，所以保留原文，求解释…） 这个流程只能用在 Confidential Client 。

参考

• OAuth 2.0 筆記