关于 OAuth 你又了解哪些？

作者罗锦华，API7.ai 技术专家/技术工程师，开源项目 pgcat，lua-resty-ffi，lua-resty-inspect 的作者。

原文链接

OAuth 的背景

OAuth，O 是 Open，Auth 是授权，也就是开放授权的意思。OAuth 始于 2006 年，其设计初衷正是委托授权，就是让最终用户也就是资源拥有者，将他们在受保护资源服务器上的部分权限（例如查询当天订单）委托给第三方应用，使得第三方应用能够代表最终用户执行操作（查询当天订单）。

OAuth 1.0 协议于 2010 年 4 月作为 RFC 5849 发布，这是一份信息性的评论请求。OAuth 2.0 框架的发布考虑了从更广泛的 IETF 社区收集的其他用例和可扩展性要求。尽管基于 OAuth 1.0 部署体验构建，OAuth 2.0 并不向后兼容 OAuth 1.0。OAuth 2.0 于 2012 年 10 月作为 RFC 6749 发布，承载令牌使用作为 RFC 6750 发布。

在 OAuth 协议中，通过为每个第三方软件和每个用户的组合分别生成对受保护资源具有受限的访问权限的凭据，也就是访问令牌，来代替之前的用户名和密码。而生成访问令牌之前的登录操作，又是在用户跟平台之间进行的，第三方软件根本无从得知用户的任何信息。

这样第三方软件的逻辑处理就大大简化了，它今后的动作就变成了请求访问令牌、使用访问令牌、访问受保护资源，同时在第三方软件调用大量 API 的时候，不再传输用户名和密码，从而减少了网络安全的攻击面。

说白了就是集中授权。

值得注意的是，OAuth 并非身份验证，这里的 Auth 是 Authorization，OAuth 是发生在用户做了身份验证后的事情，系统授权用户能做什么操作。互联网中所有的受保护资源，几乎都是以 Web API 的形式来提供访问的。不同的用户能做的事情不同，例如一个 GitHub 项目，有些用户只有读取和提交 PR（pull request）的权限，而管理员用户则能合并 PR。将用户权限在 API 层面细分，是 OAuth 要做的事情。

OAuth的授权流程

角色

在 OAuth 2.0 的体系里面有四种角色：

• 第三方应用：一般分为前端浏览器、APP 和后端应用服务器。
• 资源拥有者：使用第三方应用的用户，并在授权服务器上有账号。
• 授权服务：提供授权的开发平台，例如微博、GitHub、微信。
• 受保护资源：用户的各类信息，例如用户名、头像、昵称、邮箱等信息。

流程

步骤A：第三方应用向用户（其实是通过授权服务器）申请授权码

步骤B：授权服务器返回授权码给第三方应用

步骤C：第三方应用将授权码发给资源服务器，申请访问口令

步骤D：授权服务器返回访问口令给第三方应用

步骤E：第三方应用使用访问口令向资源服务器请求用户信息

步骤F：资源服务器返回用户信息，第三方应用提供业务逻辑给用户

授权码和访问口令

获取访问口令的方式在标准里有四种，这里只谈论授权码方式，这也是最常见最安全的方式：