Spring Security 实战干货： 简单的认识 OAuth2.0 协议

1.前言

欢迎阅读 Spring Security 实战干货 系列文章 。OAuth2.0 是近几年比较流行的授权机制，对于普通用户来说可能每天你都在用它，我们经常使用的第三方登录大都基于 OAuth2.0。随着应用的互联互通，个性化服务之间的相互调用，开放性的认证授权成为 客观的需要。

2. OAuth2.0 的简单认识

OAuth定义了如下角色，并明确区分了它们各自的关注点，以确保快速构建一致性的授权服务：

• Resource Owner 资源拥有者，通常指的是终端用户，其作用是同意或者拒绝、甚至是选择性的给第三方应用程序的授权请求。
• User Agent 用户代理 指的的资源拥有者授权的一些渠道。一般指的是浏览器、APP
• Client 请求授权和请求访问受限资源的客户端程序。
• Authorization Server 对用户授权进行鉴别并根据鉴别结果进行同意或拒绝的授权响应的服务器。
• Resource Server 能够接受和响应受保护资源请求的服务器。

单纯的文字性描述是不是有些难以理解。所以我这里讲一个亲身经历的事例来情景化以上的四个概念。马上又到程序员集中面试的季节了，有一年我去面试，到了地方才发现如此的“高大上”，访客需要通过验证码才能通过闸门，于是我联系了面试公司的HR ，后面的流程大概是这样的:

1. 我向面试公司（HR）发送了一个进门的要求。
2. HR 给了我一个可以获取进门许可请求的链接。
3. 我通过链接进行进门许可请求。
4. 请求得到响应，返给我一个验证码。
5. 我在闸门程序中输入验证码。
6. 验证通过后放行。

在我学习了 OAuth2.0 协议之后我发现这次经历可以体现出 OAuth2.0 的一些设计理念。访客必须通过授权才能访问大楼。这种方式避免了闲杂人等出入办公场所，而且对访客可控（从访问时间和次数上），甚至可以实现对楼层的访问可控（当然上面的例子中没有）。
再结合 OAuth2.0 可以知道 访客就是 Client，公司（业主）就是 Resource Owner，物业就是 Authorization Server ，那个闸机就是 Resource Server，闸机有可能也受到物业的管控。 这是那张著名的流程图：

这个例子只是为了快速的来认识 OAuth2.0 ，它是一种有效的、可靠的委托授权框架。它提供了多种授权模式在不同的场景下供你选择。

3. 授权模式

为了获得访问许可，客户端需要向授权服务器出示有效的授权凭证，也就是说客户端必须得到用户授权（authorization grant）OAuth2.0 提供了多种授权模式供开发者在不同的场景中使用，以下是授权模式的一些总结：

其中前五种为我们所熟知。我们后续会详细介绍它们。

4. OAuth 2.0 的一些要点

摘自《OAuth 2 实战》：

由于 OAuth2.0 被定义为一个框架，对于 OAuth2.0 是什么和不是什么，一直未明确。我们所说的 OAuth2.0 是指 OAuth2.0 核心规范中定义的协议，RFC 6749 核心规范详述了一系列获取访问令牌的方法；还包括其伴随规范中定义的 bearer 令牌，RFC 6750该规范规定了这种令牌的用法。获取令牌和使用令牌这两个环节是 OAuth2.0 的基本要素。正如我们将在本节中看到的，在更广泛的 OAuth2.0 生态系统中存在很多其他技术，它们配合 OAuth2.0 核心，提供更多 OAuth2.0 本身不能提供的功能。我们认为，这样的生态系统是协议健康发展的体现，但是不应与协议本身混为一谈。

基于以上的原则 OAuth2.0 有以下一些要点需要明确被认识到：

1. OAuth2.0 并非身份认证协议，虽然在授权的过程中涉及到身份认证，但是 OAuth2.0 协议本身并不处理用户的信息。客户端访问受保护的资源时并不关心资源的拥有者。
2. OAuth2.0 不提供一些消息签名，为了保证安全性所以不应脱离 Https 。在使用其它协议或者系统时也应该明确一个安全机制来承担 Https 所承担的任务。
3. OAuth2.0 并没有定义加密方式，虽然目前使用的较多的是 JOSE 规范
4. OAuth2.0 虽然令牌被客户端持有并使用，但是客户端并不能解析以及处理令牌。

5. 总结

OAuth2.0 其实还有个特点，它并不是单体协议。它被分成了多个定义和流程，每个定义和流程都有各自的应用场景。所以本文的目的在于场景化的引入 OAuth2.0，当你渐入佳境时，我们再来进行细节的探讨吧。如果你想知道更多关于 OAuth2.0 协议的相关知识，可通过我的个人网站联系我获取资料。