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 提供了多种授权模式供开发者在不同的场景中使用，以下是授权模式的一些总结：

其中前五种为我们所熟知。

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规定了一些术语用来提高我们学习的门槛:

EU：End User 终端用户

RP：Relying Party 即客户端（client），授权和认证的最终消费方，我搞不懂为啥要玩多余的概念

OP：OpenID Provider，对EU进行认证的服务提供者

ID Token：JWT格式，EU的认证通过后生成凭证，供RP消费

UserInfo Endpoint： 通过凭据查询用户基本信息的接口，建议上HTTPS。

和OAuth2不同，OIDC是需要JWT来支持的。

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迷宫图。

这个章节可以帮助你去了解OAuth2协议。关于细节部分需要根据场景去讲，涉及的东西相当的多，光RFC文档都要几十个。 协议这个东西学起来确实比较枯燥难懂，需要结合一些场景才能说清楚，不过这个是无法跳过去的东西。先不要想太多为什么，能看懂多少看懂多少，等找到场景用起来了就明白了。

在专栏后面的文章中，我会根据场景穿插介绍OAuth2.0。如果遇到疑难杂症，请联系我。

Access TCP/IP

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。