基于 OAuth 2.0 协议的授权认证

OAuth 2.0 协议

目前市面上许多产品的授权认证模块都采用的是 OAuth 2.0 协议，这个协议的核心就是向第三方应用颁发 token。第三方应用在申请 token 之前，都必须提前到系统备案，说明自己的身份。

而当第三方应用完成备案后，它会拿到两个身份识别码：

• 客户端 ID（Client ID）

• 客户端密钥（Client Secret）

这两个身份识别码将在后面的授权认证过程中起到至关重要的作用。

四个角色

• Resource Owner

  • 资源拥有者， 是有能力访问受保护资源的实体。

• Resource Server

  • 资源服务器， 托管受保护资源， 利用 Access Token 能够接受和响应受保护资源的请求。

• Client

  • 客户，是用来代表 Resource Owner 并经其授权向受保护资源发起请求的应用程序。需要注意的是，术语 Client 并非常规意义上的“客户端”，其没有具体特定的实现特征，只要是发出请求的实体都是 Client（例如运行在服务器、PC、移动设备等之上的应用程序）。

• Authorization Server

  • 授权服务器， 在认证完 Resource Owner 并获取授权成功后， 它会给 Client 颁发 Access Token。

授权流程

(A). Client 通过 User-Agent 向 Authorization Server 发起授权请求， Authorization Server 返回一个交互界面（通常为 H5 页面，让用户输入账号和密码）用于认证 Resource Owner 身份以及让其授权相关的资源。

(B). User-Agent 向用户展示授权页面并传递身份认证信息和授权确认信息给 Authorization Server。

©. Authorization Server 在认证完用户身份并确定授权成功后，重定向 User-Agent 到 (A) 提供的 Redirection URI，并带上 Auth Code 作为参数。Redirection URI 是指向 Client 的某个服务器，因此 User-Agent 最终会把 Auth Code 传给 Client 的后端服务。

(D). Client 在拿到 User-Agent 重定向过来的 Auth Code 后，不会马上应答，而是利用这个 Auth Code 请求 Authorization Server 获取 Access Token。

(E). Authorization Server 返回 Access Token 给 Client，最后 Client 应答 © 的 User-Agent 请求。

问题思考

问：为什么需要分开 Auth Code 和 Token 两次颁发？为何不在确认授权成功后直接返回 Token？

答：因为 User-Agent 不安全。

前文中我们已经提到，User-Agent 可以理解为我们通常所说的前端（通常是一个 H5 页面），而前端是不安全的。如果直接把 Token 颁发给 User-Agent，那么很容易就会被其他人盗取，进而畅行无阻地做出危害数据安全的行为。

引入 Auth Code 的概念，就是为了解决这个问题。授权服务器不会直接向 User-Agent 颁发 Token，而是先给它发送一个 Auth Code，让 User-Agent 把这个 Auth Code 交给它的后端服务，由后端服务拿着 Auth Code 来请求 Token。相较于前端，后端显然是更值得信赖的。此时我们再把 Token 颁发给后端服务，就会比之前安全很多。

你可能会提出这样一个问题：颁发 Auth Code 与颁发 Token 有什么区别呢？不还是很容易被盗取，进而用盗取来的授权码去请求 Token 吗？

此处就要揭开前文中埋下的一个伏笔了 ——

而当第三方应用完成备案后，它会拿到两个身份识别码：

• 客户端 ID（Client ID）

• 客户端密钥（Client Secret）

这两个身份识别码将在后面的授权认证过程中起到至关重要的作用。

没错，除了 Auth Code 可以用来识别身份以外，第三方的后端服务还需要拿出 Client ID 与 Client Secret 这一对身份识别码。ST 的认证服务器会同时对这三个身份识别码进行校验，只有完全匹配得上时才会去颁发 Token。其他人纵使可以盗取 Auth Code，没有 Client ID 与 Client Secret 这一对身份识别码，也是无法请求 Token 的。