rfc-6749 是你的最好的朋友
OAuth2 存在的价值
让第三方应用获取我的信息，但是我又不想让第三方知道我的密码。
OAuth2 的 Protocol Flow
+--------+ +---------------+
| |--(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 ---| |
+--------+ +---------------+
注解：
Resource Owner: 例如，用户。第一个流程实际上就是让用户在授权页面点击授权。
按照 Google OAuth2 的文档说明，第一个流程和第二个流程有时会是合并的。
- Two-legged OAuth: 如果第一步就返回 access token, 则不需要进行第二部
- Three-legged OAuth: 否则，需要从第一步获得 authorization code, 然后用这个 code 获得 access token
Two-legged OAuth、Three-legged OAuth 不同的使用场景:
- Three-legged OAuth 在所有流程之前，三方应用需要注册一个 client_id, 和 client_secret.
- 在获取 access token 的时候，需要同时提供用户的 authorization code, 和三方应用的 client_id, client_secret. 实现 double check.
- 但是，这样做的前提是 client_id, client_secret 不会泄漏，而客户端授权的三方应用(js, 或移动客户端)则无法隐藏 client_id, client_secret, 所以只需要使用 two-legged OAuth
- 也就是说，two-legged oauth 下, 任何人获得了 access token 就能直接访问用户的数据
Refresh 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
Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
也就是说在获得 access token 时，会同时获得到一个 refresh token. 但是这个 refresh token 不是用来和 resource server 打交道的，而是当 access token 过期时，用来和从 authorization server 换取新 access token 时使用。 同时，获得一个新的 refresh token.
豆瓣的 OAuth 文档验证了这一点：
在access_token使用过程中，如果服务器返回106错误：“access_token_has_expired ”， 此时，说明access_token已经过期，除了通过再次引导用户进行授权来获取access_token 外，还可以通过refresh_token的方式来换取新的access_token和refresh_token。
注解:
access token， refresh token 的有效期不一样，refresh token 更长。同时针对不同 级别的三方应用，这两个的有效期也不一样。
以豆瓣为例：
| 级别 | access_token有效期 | refresh_token有效期 | 说明 | | -- | -- | -- | -- | | L1 | 7天 | 14天 | | | L2 | 30天 | 60天 | | | L3 | 90天 | 180天 | |
参考
- Using OAuth 2.0 to Access Google APIs
- rfc6749 - The OAuth 2.0 Authorization Framework
- 使用OAuth2.0访问豆瓣API
- What is the difference between access tokens and auth_codes in OAuth 2
- OAuth 2.0 : Difference between 2 workflows - When to use Authorization Code flow?
微信关注我哦 👍
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式