【OAuth2】二、OAuth2的授权方式

一、OAuth2的角色

还可以参考这片文章：https://blog.csdn.net/weixin_44446512/article/details/126109616

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

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

二、 认证流程

三、授权模式

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

授权方式	客户端类型/用例
Authorization code	旨在用于具有后端的传统Web应用程序以及本机（移动或桌面）应用程序，以利用通过系统浏览器的单点登录功能
Authorization code	旨在用于具有后端的传统Web应用程序以及本机（移动或桌面）应用程序，以利用通过系统浏览器的单点登录功能
Implicit（2.1过时）	适用于不带后端的基于浏览器的（JavaScript）应用程序，已经不推荐使用。
Password（2.1过时）	对于应用程序和授权服务器属于同一提供程序的受信任本机客户端，已经不推荐使用。
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 的一些要点

摘自《OAuth 2 实战》：

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

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

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

2、OAuth2的几个误区

• OAuth2客户端无法认定资源拥有者就是正确的拥有者，它没有鉴别能力，虽然市面上的OAuth2能够保证授权的安全性，但是OAuth2本身并没有对用户认证提供明确的规范，OAuth2协议仅仅是授权协议。

• OAuth2和JWT没有必然关系，OAuth2只要不使用JWT bearer模式，就可以不使用JWT。

• OAuth2现在不仅仅指的是OAuth2.0，还有可能是最新的OAuth2.1。

六、OIDC

OIDC是OAuth2的一个内建协议，是对OAuth2的一个补充，它支持对资源拥有者的认证。

1、 OIDC的关键术语

OIDC规定了一些术语用来提高我们学习的门槛:

• EU： End User 终端用户
• RP： Relying Party 即客户端（client），授权和认证的最终消费方。
• OP： OpenID Provider，对EU进行认证的服务提供者
• ID Token：JWT格式，EU的认证通过后生成凭证，供RP消费
• UserInfo Endpoint： 通过凭据查询用户基本信息的接口，建议上HTTPS。
  和OAuth2不同，OIDC是需要JWT来支持的。

2、OIDC 的大致流程

OIDC复用了OAuth2的授权流程，在授权的过程中增加了一些“小动作”来进行用户认证。结合其术语，大致的流程是这样的：

• RP发送一个认证请求给OP；
• OP先对EU进行身份认证，确认无误后提供授权；
• OP把ID Token和Access Token（需要的话）返回给RP；
• RP使用Access Token发送一个请求UserInfo EndPoint；（可选）
• UserInfo EndPoint返回EU的Claims。（基于第4个步骤可选）

3、总结：OIDC比OAuth2多一个功能，可以做用户认证。

七、总结

OAuth2 其实还有个特点，它并不是单体协议。它被分成了多个定义和流程，每个定义和流程都有各自的应用场景，因此它非常庞大，一不小心就容易陷入迷宫要结合对应的特点来。