OAuth 2.0 授权码模式登录流程全图

(1) 前端重定向到认证中心（请求登录）

目的：让认证中心确认“用户是谁”

用户点击“登录”按钮后，前端把浏览器跳转到认证中心。我们跳转的url中通常要包含以下信息：

• client_id：告诉认证中心是哪个应用在请求登录
• redirect_uri：登录成功后跳回哪里
• state：随机字符串，用于防攻击

跳转之后，用户将会在认证中心登录，输入在认证中心的平台上的用户名密码等，这都和我们的应用无关。我们只要知道，跳转走了之后的安全都不是我们负责，认证中心负责分辨「来者何人」。

(2) 认证中心登录成功，重定向回前端并携带 code

目的：认证中心告诉我们的系统：“用户已经登录成功”

认证中心验证用户成功后，浏览器被重定向回我们的前端应用，例如

text
1https://app.example.com/callback?code=abc123&state=random123

前端获得：

• code：授权码（临时凭证）
• state：用于校验请求合法性

这个授权码我们的前端拿着什么也做不了，它唯一的用途就是由我们的后端应用向认证中心的服务器换取登录的细节信息。这个 code 只能用一次，而且一般短时间就过期。

(3) 前端把 code 发送给后端

原因上文已解释。

(4) 后端用 code 向认证中心验证用户身份

后端请求认证中心，至少要提交以下信息给认证中心：

• client_id
• client_secret
• code

前两者都是我们与认证中心约定好的（或者说认证中心授权给我们的），我们此时提交，表明自己是受信任的后端。同时这个 code 就是认证中心刚刚签发的，它自然可以验证这个 code 是否是由「一个有效的用户」、刚刚在登录「这个 client_id 的应用」的时候「登录成功」之后由自己签发的。如果验证通过，认证中心将会给我们一些信息，这些信息至少保证在我们的系统里能唯一确定某个用户。

而 client_secret 就是这个 code 除了我们的后端其它任何人/任何程序拿到都没什么用处的原因。

(5) 后端查询自己的数据库，确认用户情况

认证中心只负责确认身份，它完全不 care 我们的系统的任何业务细节。此时和认证中心的交互已经全部完成，后续都只是一个普通的「账号密码登录」也需要走的流程。

比如说，这个用户在我们系统里可能是管理员，可能是普通用户，可能我们的登录接口要返回用户的头像；再比如，这个用户可能在我们的系统里不存在，那用户选了「通过微信登录」，我们是自动创建新用户还是要求用户绑定手机号？诸如此类事项，都是认证中心所不关心的。

(6) 后端签发 JWT 给前端

参考https://www.elecmonkey.com/blog/note-jwt。

当然也可以用 session 模式，根据资源和业务场景而定。