Skip to the content.

OAuth2学习笔记

2017-12-07

概念

OAuth 2.0 的角色定义

Clients

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

EndPoints

在 OAuth 2.0 里面,Endpoints (数据传输端点)共有三种:

流程

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 里面的应用程序。但也因此有外泄风险,例如:

因为要实施转址,所以 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 。这中流程只有在以下情况才能使用:

而就算 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 。

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

参考