Skip to content 后端-从Oauth到Oauth2
1. Oauth 是为了解决什么问题
Oauth 是一个用户鉴权认证的协议，为了解决多平台、多场景的身份认证问题。一言以蔽之：解决的最核心问题：如果在资源所有者和第三方之间共享授权信息，无需暴露用户的登录凭证。- 设计目的是为了实现跨平台认证，而不泄露用户的登录凭证，比如用户名和密码。
- 比如我的朋友需要临时进入我家，我不希望将钥匙给他，因为那样可能会泄露我的钥匙，存在安全问题。 我应该发放一个凭证给他，这个凭证里面记录了他的有关信息，当他来到门禁的时候，通过凭证进行校验即可。将来他回去了，这个凭证也可以进行回收。
- 不妨以这个场景为例，说明
Oauth2 认证的大体流程： - 授权请求：朋友来到我家门口，但是被门禁挡住了，需要发出授权请求。
- 我的同意：我通过远程操作，告诉门禁机器，允许他进入。
- 发放令牌：门禁录入他的有关信息，注明了他是谁、他允许去哪里、他的令牌何时过期。
- 访问授权：朋友通过令牌顺利进入我家进行游玩。
- 撤销访问权：朋友回家之后，门禁令牌自动失效，他无法再次进入小区。
- 总结一下，令牌的好处有三点：
- 能够控制访问资源的范围；
- 能够控制有效时间；
- 能够随时进行撤回；
2. 从 Oauth 到 Oauth2
- 认证流程：
Oauth 1.0 主要提供了标准的认证流程，但是方式相对单一，在复杂场景下的泛化能力不足。 - 取消签名过程：
Oauth 2.0 取消了 1.0 的签名过程，全程使用 HTTPS 进行安全传输。 - 增强适用性：
Oauth 2.0 对资源服务器和授权服务器的角色进行了更新清晰的定义，使得浏览器、移动应用、桌面应用、后端服务之间的授权更加明确，扩大了使用场景。 - 令牌类型多样化：可以采用
Bearer 令牌，也可以 MAC 令牌，为不同的安全需求都提供了便利。
3. 主要角色
- 资源所有者（
Resource Owner）：资源所有者是最终用户，他拥有受保护的资源，例如用户的照片或社交媒体帖子。 - 客户端（
Client）：客户端是请求访问受保护资源的应用程序，例如Web应用程序或移动应用程序。 - 授权服务器（
Authorization Server）：授权服务器负责验证资源所有者的身份并颁发访问令牌给客户端。 - 资源服务器（
Resource Server）：资源服务器存储和提供受保护的资源，只有在有效的访问令牌下才能访问。
4. Oauth2 的 4 种场景
3.1 授权码模式
- 是目前最主流、最常见的的方式
- 一般来说，分成以下几个主要的步骤：
- 客户端重定向用户到授权服务器，请求授权。
- 用户登录并授权客户端。
- 授权服务器将授权码返回给客户端。
- 客户端使用授权码向授权服务器请求访问令牌。
- 授权服务器验证授权码，并颁发访问令牌给客户端。
3.2 隐藏式
- 纯前端的应用，没有后端，所以必须将令牌存储在前端，允许直接向前端颁发令牌，所有没有授权码这个概念。
- 过程如下：
- 第一步，
A 提供链接，要求用户跳转到 B，授权用户数据给目标网站使用。 - 第二部，用户跳转到
B，登录后同意授权，那么，令牌就会放在 URL 当中，发放回 A。
3.3 密码式
- 如果高度信任某个应用，可以将用户名和密码直接告诉该应用，然后使用密码登录。
3.4 凭证式
- 最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。
5. 安全方面的顾虑
OAuth 2.0 有一些安全性考虑，包括： CSRF 攻击（跨站请求伪造）： 攻击者试图通过伪造用户的身份来获得授权码。- 令牌泄漏： 如果访问令牌泄漏，攻击者可以访问用户的资源。
- 未经授权的客户端： 未经授权的客户端可能会尝试访问受保护的资源。
6. JWT 可以工作在 Oauth2 场景下
JWT 是一种轻量级的令牌格式，通常用于在 OAuth 2.0 中表示访问令牌。它可以包含有关用户或客户端的信息，以及令牌的有效期等信息。OAuth 2.0 规范并没有要求使用 JWT ，但它是一种常见的令牌格式选择，因为它具有自包含性和安全性。
2024-02-22