OAuth 2.0
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 ---| |
+--------+ +---------------+
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 +---------------+
Authorization Code Grant
+----------+
| 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)
- 通过前端渠道客户获取授权码
- 通过后端渠道,客户使用authorization code去交换access Token和可选的 refresh token
- 假定资源拥有者和客户在不同的设备上
- 最安全的流程,因为令牌不会传递经过user-agent
Implicit Grant
+----------+
| 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)------- ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
- 适用于公开的浏览器单页应用
- Access Token直接从授权服务器返回(只有前端渠道)
- 不支持refresh tokens
- 假定资源所有者和公开客户应用在同一个设备上
- 最容易受安全攻击
Resource Owner Password Credentials Grant
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
- 使用用户名密码登录的应用,例如桌面App
- 使用用户名/密码作为授权方式从授权服务器上获取access token
- 一般不支持refresh tokens
- 假定资源拥有者和公开客户在相同设备上
Client Credentials Grant
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
- 适用于服务器间通信场景,机密客户代表它自己或者一个用户
- 只有后端渠道,使用客户凭证获取一个 access token
- 因为客户凭证可以使用对称或者非对称加密,该方式支持共享密码或者证书
Reference
继续阅读与本文标签相同的文章
上一篇 :
动态sql和分页
-
200多万市民实现办事“免交证明”,阿里助力晋城数字化升级
2026-05-19栏目: 教程
-
聚游:颠覆传统规则 构筑区块链游戏新生态
2026-05-19栏目: 教程
-
跟并列式人民日报时评学布局谋篇
2026-05-19栏目: 教程
-
阿里开发者技术交流钉钉群汇总【2019】
2026-05-19栏目: 教程
-
9月书讯:别抱怨读书苦,那是你看世界的路
2026-05-19栏目: 教程
