4-OAuth2.0协议简单认识
上一篇胖哥和大家一起通过日志分析了Spring Security OAuth2的authorization_code模式，相信流程你已经了解了一些。但是你会不会有这样的疑问，用户访问客户端自己的资源/foo/hello为啥还要跳到第三方gitee登录？正常情况下自己的资源只要自己认证就能访问，借助于其它平台认证授权是怎么回事？
解惑
Spring Security OAuth2 Login纯粹是“借别人的鸡下自己的蛋”。真正的目的是授权去访问/v5/user获得gitee平台当前用户的信息，借第三方平台的用户注册信息来给客户端平台做自己的认证，我们无条件地信任了gitee用户。 如果第三方平台不开放user-info-uri 获取用户注册信息的话，OAuth2 Login就做不成。
我个人认为Spring Security的OAuth2 Login是在OAuth2授权的基础上自行实现的认证。
/foo/hello的访问控制还是Spring Security自有的机制，和OAuth2无关。
OAuth2 的简单认识
OAuth2定义了如下角色，并明确区分了它们各自的关注点，以确保快速构建一致性的授权服务：
- Resource Owner 资源拥有者，通常指的是终端用户，其作用是同意或者拒绝、甚至是选择性的给第三方应用程序的授权请求。
- User Agent 用户代理，发起请求的客户端。一般指的是浏览器、APP。
- Client 请求授权和请求访问受限资源的客户端程序。
- Authorization Server 对用户授权进行鉴别并根据鉴别结果进行同意或拒绝的授权响应的服务器。
- Resource Server 能够接受和响应受保护资源请求的服务器。
这是那张著名的流程图：
这个例子只是为了快速的来认识 OAuth2.0 ，它是一种有效的、可靠的委托授权框架。它提供了多种授权模式在不同的场景下供你选择。
授权模式
为了获得访问许可，客户端需要向授权服务器出示有效的授权凭证，也就是说客户端必须得到用户授权（authorization grant）OAuth2 提供了多种授权模式供开发者在不同的场景中使用，以下是授权模式的一些总结：
| 授权方式 | 客户端类型/用例 |
|---|---|
| Authorization code | 旨在用于具有后端的传统Web应用程序以及本机（移动或桌面）应用程序，以利用通过系统浏览器的单点登录功能。 |
| 适用于不带后端的基于浏览器的（JavaScript）应用程序，已经不推荐使用。 | |
| 对于应用程序和授权服务器属于同一提供程序的受信任本机客户端，已经不推荐使用。 | |
| 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 | 使用代理模拟的方式获取令牌 |
其中前五种为我们所熟知。
OAuth2的使用场景
OAuth2都用于哪些场景呢？这里我大致罗列了一下，主要有以下几个场景：
千万不要搞错了使用场景，把简单的问题复杂化。
OAuth2 的一些要点
摘自《OAuth 2 实战》：
由于 OAuth2.0 被定义为一个框架，对于 OAuth2.0 是什么和不是什么，一直未明确。我们所说的 OAuth2.0 是指 OAuth2.0 核心规范中定义的协议，RFC 6749 核心规范详述了一系列获取访问令牌的方法；还包括其伴随规范中定义的 bearer 令牌，RFC 6750该规范规定了这种令牌的用法。获取令牌和使用令牌这两个环节是 OAuth2.0 的基本要素。正如我们将在本节中看到的，在更广泛的 OAuth2.0 生态系统中存在很多其他技术，它们配合 OAuth2.0 核心，提供更多 OAuth2.0 本身不能提供的功能。我们认为，这样的生态系统是协议健康发展的体现，但是不应与协议本身混为一谈。
基于以上的原则 OAuth2 有以下一些要点需要明确被认识到：
- OAuth2 并非身份认证协议，虽然在授权的过程中涉及到身份认证，但是 OAuth2协议本身并不处理用户的信息。客户端访问受保护的资源时并不关心资源的拥有者。
- OAuth2不提供一些消息签名，为了保证安全性所以不应脱离 Https 。在使用其它协议或者系统时也应该明确一个安全机制来承担 Https 所承担的任务。
- OAuth2并没有定义加密方式，虽然目前使用的较多的是 JOSE 规范
- OAuth2虽然令牌被客户端持有并使用，但是客户端并不能解析以及处理令牌。
OAuth2应该建立在HTTPS协议之上。
OAuth2的几个误区
-
OAuth2客户端无法认定资源拥有者就是正确的拥有者，它没有鉴别能力，虽然市面上的OAuth2能够保证授权的安全性，但是OAuth2本身并没有对用户认证提供明确的规范，OAuth2协议仅仅是授权协议。
-
OAuth2和JWT没有必然关系，OAuth2只要不使用JWT bearer模式，就可以不使用JWT。
-
OAuth2现在不仅仅指的是OAuth2.0，还有可能是最新的OAuth2.1。
OIDC
OIDC是OAuth2的一个内建协议，是对OAuth2的一个补充，它支持对资源拥有者的认证。
OIDC的关键术语
OIDC规定了一些术语用来提高我们学习的门槛:
EU：End User 终端用户RP：Relying Party 即客户端（client），授权和认证的最终消费方，我搞不懂为啥要玩多余的概念OP：OpenID Provider，对EU进行认证的服务提供者ID Token：JWT格式，EU的认证通过后生成凭证，供RP消费UserInfo Endpoint： 通过凭据查询用户基本信息的接口，建议上HTTPS。
和OAuth2不同，OIDC是需要JWT来支持的。
OIDC 的大致流程
OIDC复用了OAuth2的授权流程，在授权的过程中增加了一些“小动作”来进行用户认证。结合其术语，大致的流程是这样的：
- RP发送一个认证请求给OP；
- OP先对EU进行身份认证，确认无误后提供授权；
- OP把ID Token和Access Token（需要的话）返回给RP；
- RP使用Access Token发送一个请求UserInfo EndPoint；（可选）
- UserInfo EndPoint返回EU的Claims。（基于第4个步骤可选）
看不懂流程没有关系，知道OIDC比OAuth2多一个功能，可以做用户认证就行了。
小结
OAuth2 其实还有个特点，它并不是单体协议。它被分成了多个定义和流程，每个定义和流程都有各自的应用场景，因此它非常庞大，一不小心就容易陷入迷宫。以下来自It’s time for OAuth2.1的OAuth2迷宫图。
![[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wod9mKj1-1647439290067)(.\img\oauth-maze.png)]](https://img-blog.csdnimg.cn/66f66d39a65b444b8c6babd3156f09ac.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA56CB5Yac5bCP6IOW5ZOl,size_20,color_FFFFFF,t_70,g_se,x_16)
这个章节可以帮助你去了解OAuth2协议。关于细节部分需要根据场景去讲，涉及的东西相当的多，光RFC文档都要几十个。 协议这个东西学起来确实比较枯燥难懂，需要结合一些场景才能说清楚，不过这个是无法跳过去的东西。先不要想太多为什么，能看懂多少看懂多少，等找到场景用起来了就明白了。
在专栏后面的文章中，我会根据场景穿插介绍OAuth2.0。如果遇到疑难杂症，请联系我。
文章来源: felord.blog.csdn.net，作者：码农小胖哥，版权归原作者所有，如需转载，请联系作者。
原文链接：felord.blog.csdn.net/article/details/123537835
- 点赞
- 收藏
- 关注作者
评论（0）