OAuth2.0系列文章 - 为什么我们需要引入OAuth2.0

1. 写在前面的话

我之前参与过一个OpenAPI的项目，其业务形态非常简单，一句话就可以说清楚：第三方应用想要来调用我们系统的接口，以获取我们的内部数据。OpenAPI项目最关键的一点，就是要解决对外接口的安全性问题，比如最基础的：

• 谁能调用我们系统的接口？
• 他有权限调用哪些接口？

在技术选型的阶段，我们阅读了一些国内做OpenAPI的厂商的公开资料，很自然的就找到了 OAuth2.0这个主流的授权框架，但当我搜索相关资料尝试弄明白这个框架时，却遇到了问题：很多关于OAuth2.0的博客都偏理论，而且内容高度雷同，了解概念有余，但想依靠这些信息来搭建一套安全的OpenAPI平台还是有所不足。为此，我们团队又花了很多时间去阅读OAuth2.0相关的规范文档，对我们比较有帮助的文档如下：

• 理论基础：RCF 6749《The OAuth 2.0 Authorization Framework》
• 实践支撑：Financial-grade API (FAPI) Final Specifications

也是在做OpenAPI项目的期间，对OAuth2.0有了一些比较粗浅的理解，这里整理记录下来，以作回顾。
本篇是该系列的第一篇，主要介绍OAuth2.0要解决什么问题。

2. 认证授权就是用户名密码？

我在做OpenAPI项目之前，一直觉得认证授权是一件很简单的事情，就像宋丹丹要把大象装冰箱一样，总共只需要三步：

1. 用户在浏览器中输入用户名和密码，点击登录；
2. 服务端接收到用户名和密码信息，校验其正确性，成功则返回登录令牌；
3. 浏览器接收到登录令牌，后续向服务端发送的请求都会携带该登录令牌用于身份校验；

流程大致如下图所示：

是吧？相信很多人跟我一样，一提到认证授权的时候，脑子里第一时间想到的流程就是这样的。但我转念一想，不对啊，这三步顶多也就百来行代码能解决的事情，为什么有的公司专门招了几十号人在做认证授权系统，甚至还有一些公司靠提供 IDaas 的服务做到几十亿市值？
奇怪，资本家不可能有错，有错的一定是我自己。所以我们扩展一点来想，除了使用用户名密码登录这种最常见的认证授权场景外，还有哪些场景是值得我们探究的？

3. 名词统一

在开脑洞前，我们先来归纳一下上面这个最简单的认证授权场景里的一些主体，统一一下名词概念，避免我说的跟你理解的不一致&#