OAuth 2.0 学习笔记
¶参考资料
- 阮一峰 理解OAuth 2.0
- OAuth 2.0 官方文档 RFC6749
- 中文非常好的同学可以看此中文翻译 (LOL)
¶授权方式
客户端（Client）征求用户（Resource Owner/User）的授权获得访问凭证（Access Token）的过程。
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
授权（Authorization Grant）方式有如下四种类型：
¶Authorization Code
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
User 与 client 之前存在无法完全信任的用户代理（User-Agent）时，使用这种方式避免直接将 access token 转交给 user-agent，而是增加一个 authorization code 步骤，让 Client 直接向认证服务器（Authorization Server）索要 access token 。
¶Implicit
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two
parts as they pass through the user-agent.
Figure 4: Implicit Grant Flow
上一种方式的减化版本，因为省去了 authorization code 这步，所以速度更快且更方便，但安全性较低。通常在 user-agent 即 client 的环境下使用，例如网页小程序或者浏览器插件。在这样的环境中，通常 token 的期限不会给的太长。
¶Resource Owner Password redentials
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 5: Resource Owner Password Credentials Flow
Client 使用用户的密码作为凭证，直接向 authorization server 获取 access token 以及 refresh token，通常只要在最开始时使用一次，所以理论上 client 不得保存用户的密码。一般在用户非常信任的环境中使用，例如用户自己的手机操作系统。
¶Client Credentials
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials Flow
客户端向 authorization server 获取自己已有权限的子集，可以将获得到的子集 access token 交给它的子客户端使用。
¶基本概念
¶Access Token
由认证服务器和资源服务器共同实施的一种凭证。由于该 token 是在用户的授权下产生的，所以资源服务器可以为出示此 token 的客户提供相应的资源。
¶Refresh Token
当 access token 过期或无效后，client 使用 refresh token 重新向认证服务器申请新的 access token 。
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token
Access token 无效的情况可能发生在相关验证或解密算法变更的情况下。refresh token 结构较为单一，可以不受影响。当用户修改密码时，access token 和 refresh token 同时失效。
Token 必须是无法伪造的，可以是简单的 GUID（用于在数据库中检索相关权限），也可以是包含丰富信息（如作用域，过期时间等）的加密字符串。具体的实现可以根据需求自行变更。
¶OAuth 2.0 实现
官方网站提供了各种语言的开源实现 http://oauth.net/2/