1.前言

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

2. OAuth2.0 的简单认识

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

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

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

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

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

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

3. 授权模式

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

授权方式	客户端类型/用例
Authorization code	旨在用于具有后端的传统Web应用程序以及本机（移动或桌面）应用程序，以利用通过系统浏览器的单点登录功能。
Implicit	适用于不带后端的基于浏览器的（JavaScript）应用程序。
Password	对于应用程序和授权服务器属于同一提供程序的受信任本机客户端。
Client credentials	客户端以自己的名义来获取许可，而不是以终端用户名义，或者可以说该用户端也是资源拥有者
Refresh token	令牌失效后使客户端可以刷新其访问令牌，而不必再次执行代码或密码授予的步骤。
SAML 2.0 bearer	使拥有SAML 2.0断言（登录令牌）的客户端将其交换为OAuth 2.0访问令牌。
JWT bearer	拥有一个安全域中的JSON Web令牌断言的客户端将其交换为另一域中的OAuth 2.0访问令牌。
Device code	设备的唯一编码，一般该编码不可更改，多用于一些智能设备
Token exchange	使用代理模拟的方式获取令牌

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

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 有以下一些要点需要明确被认识到：

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

5. 总结

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

关注公众号：Felordcn获取更多资讯

个人博客：https://felord.cn