OAuth 2.0 标准的 RFC 比较难读懂,本文尽量把认证流程说明白。

认证方式

OAuth 2.0 共有 4 种访问模式[1]

  • 授权码模式(Authorization Code),适用于一般服务器端应用
  • 简化模式(Implicit),适用于纯网页端应用,不过现在推荐使用 PKCE 作为替代
  • 密码模式(Resource owner password credentials),不介绍
  • 客户端模式(Client credentials),不介绍

另外注意 OAuth 服务本身必须是 HTTPS 的,而三方应用可以是 HTTP 的。

Authorization Code

假设我们的网站有一个功能是同步用户在 Github 的所有仓库。对接 OAuth 流程大致分为 5 个步骤:

  1. 在 Github 的 OAuth 页面上注册网站信息。在网站发布前就要做好
  2. 用户点击网站上的“同步 Github 仓库”按钮,开始 OAuth 认证流程
  3. 浏览器弹出 Github 认证窗口,询问“是否允许网站 XXX 的访问”,用户点击“允许”
  4. Github 得知用户点了“允许”后,生成授权码(Authorization Code),并将用户重定向到我们的网站里,网站后台收到授权码后,向 Github 请求ACCESS_TOKEN
  5. 网站后台从 Github 收到 ACCESS_TOKEN,接着向 Github 拉取该用户所有的仓库

具体流程如下图:

在授权码方式下,ACCESS_TOKEN 只会存在我们网站的服务器里,用户端从始至终都获取不到这个信息,我们不必害怕用户的电脑中毒了而导致 ACCESS_TOKEN 泄露。

(更多安全相关的考虑参考最后的参考文章)

Implicit

Implicit 是为纯网页应用设计的,与 Authorization Code 模式相比:

  • Implicit 模式认证过程中,不使用 CLIENT_SECRET
  • 用户认证后直接拿到 ACCESS_TOKEN 不再需要通过 Authorization Code 进行中转(下图的步骤 ⑥)

整体流程如下图:

Implicit 设计之初,由于浏览器的同源策略,不允许跨站请求,因此 Authorization Code 不可行[2]。现在由于浏览器普遍支持 CORS,且 Implicit 本身也在安全风险,目前建议使用 PKCE[3]

小结

OAuth 2.0 是广泛使用的授权标准,设计的本身也有许多安全性的考量。本文浅尝辄止,只介绍 Authorization Code 与 Implicit 模式的授权过程,而这些流程背后想要解决的问题,需要另选学习。

参考


  1. https://auth0.com/docs/api-auth/which-oauth-flow-to-use

  2. Secure Your SPA with Authorization Code Flow with PKCE

  3. OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-09