OAuth 2.0 作用及工作流程是什么？OAuth 2.0 有哪些应用场景？OAuth 2.0历史又是如何演进的？希望读完本文，能帮您解答这些疑惑！
一、OAuth 2.0 作用及工作流程
OAuth 2.0 作用
OAuth 2.0 是一个授权框架，主要作用是提供第三方应用安全访问资源所有者受保护的资源，而不需要暴露用户的凭据（如密码）。它通过颁发访问令牌（Access Token）来实现这一点，这些令牌在特定的时间内允许第三方应用访问资源服务器上的资源。
详细工作流程
以下是 OAuth 2.0 授权码模式的详细工作流程：
- 用户访问客户端：用户通过浏览器访问客户端应用，客户端引导用户进行身份验证。
- 重定向到授权服务器：客户端将用户重定向到授权服务器，请求用户授权。
- 用户授权：用户在授权服务器上进行身份验证并授予客户端访问权限。
- 返回授权码：授权服务器将用户重定向回客户端，同时附带一个授权码。
- 客户端请求访问令牌：客户端向授权服务器发送授权码，并请求访问令牌。
- 授权服务器返回访问令牌：授权服务器验证授权码，并返回访问令牌和刷新令牌。
- 客户端访问资源服务器：客户端使用访问令牌访问资源服务器上的受保护资源。
- 资源服务器验证令牌：资源服务器验证访问令牌，并返回请求的资源。
Mermaid 图示
通过 OAuth 2.0，用户可以安全地授权第三方应用访问他们的资源，而不需要暴露个人凭据，极大地提高了安全性和用户体验。
二、OAuth 2.0 社交登录场景举例
应用场景
用户希望使用已有的社交媒体账号（如 Google）登录第三方应用或网站。
举例：用户使用 Google 账号登录新闻网站
- 用户访问新闻网站，选择使用 Google 账号登录。
- 新闻网站将用户重定向到 Google 的授权服务器，请求用户授权。
- 用户在 Google 授权服务器上进行身份验证并同意授权。
- Google 授权服务器将用户重定向回新闻网站，并附带授权码。
- 新闻网站使用授权码向 Google 请求访问令牌。
- Google 返回访问令牌给新闻网站。
- 新闻网站使用访问令牌向 Google 请求用户的基本信息。
- Google 返回用户的基本信息，新闻网站使用这些信息创建或更新用户的账户。
Mermaid 图示
详细步骤说明
-
用户访问新闻网站：
- 用户打开新闻网站，并选择“用 Google 登录”。
-
重定向到 Google 授权服务器：
- 新闻网站将用户重定向到 Google 的授权服务器，请求用户授权。
- 请求中包含客户端 ID、重定向 URI、请求的权限范围（scope）和状态信息。
-
用户在 Google 授权服务器上登录并授权：
- 用户在 Google 授权服务器上登录（如果尚未登录）。
- Google 向用户展示请求的权限范围，用户同意授权。
-
返回授权码：
- Google 授权服务器验证用户身份并同意授权后，将用户重定向回新闻网站，并附带一个授权码。
-
新闻网站请求访问令牌：
- 新闻网站接收到授权码后，向 Google 授权服务器发送一个请求，包含授权码、客户端 ID、客户端密钥和重定向 URI，请求访问令牌。
-
Google 授权服务器返回访问令牌：
- Google 授权服务器验证授权码，如果验证成功，则返回访问令牌。
-
新闻网站请求用户信息：
- 新闻网站使用访问令牌向 Google 资源服务器请求用户的基本信息（如用户名、电子邮件等）。
-
Google 返回用户信息：
- Google 资源服务器验证访问令牌，并返回用户的基本信息。
-
新闻网站欢迎用户：
- 新闻网站使用获取到的用户信息创建或更新用户的账户，并显示个性化的信息给用户。
通过这个流程，新闻网站实现了安全的第三方登录，而用户只需使用已有的 Google 账号，无需重新创建新账号或提供密码。
三、OAuth 2.0使用 GitHub 登录第三方应用举例
应用场景
使用 GitHub 账号登录第三方应用
举例：用户使用 GitHub 账号登录一个项目管理工具
- 用户访问项目管理工具网站，选择使用 GitHub 账号登录。
- 项目管理工具将用户重定向到 GitHub 的授权服务器，请求用户授权。
- 用户在 GitHub 授权服务器上进行身份验证并同意授权。
- GitHub 授权服务器将用户重定向回项目管理工具网站，并附带授权码。
- 项目管理工具使用授权码向 GitHub 请求访问令牌。
- GitHub 返回访问令牌给项目管理工具。
- 项目管理工具使用访问令牌向 GitHub 请求用户的基本信息。
- GitHub 返回用户的基本信息，项目管理工具使用这些信息创建或更新用户的账户。
Mermaid 图示
详细步骤说明
-
用户访问项目管理工具网站：
- 用户打开项目管理工具网站，并选择“用 GitHub 登录”。
-
重定向到 GitHub 授权服务器：
- 项目管理工具将用户重定向到 GitHub 的授权服务器，请求用户授权。
- 请求中包含客户端 ID、重定向 URI、请求的权限范围（scope）和状态信息。
-
用户在 GitHub 授权服务器上登录并授权：
- 用户在 GitHub 授权服务器上登录（如果尚未登录）。
- GitHub 向用户展示请求的权限范围，用户同意授权。
-
返回授权码：
- GitHub 授权服务器验证用户身份并同意授权后，将用户重定向回项目管理工具网站，并附带一个授权码。
-
项目管理工具请求访问令牌：
- 项目管理工具接收到授权码后，向 GitHub 授权服务器发送一个请求，包含授权码、客户端 ID、客户端密钥和重定向 URI，请求访问令牌。
-
GitHub 授权服务器返回访问令牌：
- GitHub 授权服务器验证授权码，如果验证成功，则返回访问令牌。
-
项目管理工具请求用户信息：
- 项目管理工具使用访问令牌向 GitHub 资源服务器请求用户的基本信息（如用户名、电子邮件等）。
-
GitHub 返回用户信息：
- GitHub 资源服务器验证访问令牌，并返回用户的基本信息。
-
项目管理工具欢迎用户：
- 项目管理工具使用获取到的用户信息创建或更新用户的账户，并显示个性化的信息给用户。
通过这个流程，项目管理工具实现了安全的第三方登录，用户只需使用已有的 GitHub 账号，无需重新创建新账号或提供密码。
四、OAuth 2.0历史演进
OAuth 2.0 的发展历程涵盖了从最初的设计概念到成为广泛应用的行业标准的过程。下面是 OAuth 2.0 历史演进的主要阶段：
1. OAuth 1.0 的起源
- 2007年：OAuth 1.0 协议首次提出，解决了 Web 应用程序如何安全地授权第三方访问资源的问题。OAuth 1.0 使用了复杂的签名机制，并要求双方在通信中使用安全的密钥。
2. OAuth 2.0 的设计和草案
- 2010年：OAuth 2.0 工作组成立，开始设计 OAuth 2.0 协议，旨在简化授权流程，提升用户体验，并支持更广泛的应用场景。OAuth 2.0 相较于 OAuth 1.0 简化了授权流程，移除了复杂的签名机制。
- 2011年：OAuth 2.0 的草案发布，介绍了新的授权模式（如授权码模式、简化模式、密码模式和客户端凭证模式），并提出了访问令牌的概念。
3. OAuth 2.0 的标准化
- 2012年：OAuth 2.0 的核心规范成为正式标准。主要的标准文档包括：
- RFC 6749（Authorization Framework）：定义了 OAuth 2.0 的授权框架。
- RFC 6750（Bearer Token Usage）：定义了访问令牌的使用方式。
4. OAuth 2.0 的扩展
- 2014年：引入了 PKCE（Proof Key for Code Exchange），旨在增强授权码模式的安全性，尤其在公共客户端（如移动应用）中，防止授权码被拦截和重用。
- 2015年：OpenID Connect（OIDC）发布，这是一个建立在 OAuth 2.0 之上的身份层，提供了用户身份验证功能。它扩展了 OAuth 2.0 的功能，实现了单点登录（SSO）和用户信息的标准化获取。
5. OAuth 2.1 的发布
- 2018年：OAuth 2.1 草案发布，旨在整合和简化 OAuth 2.0 的多个规范，去除不再推荐的功能，提升安全性和用户体验。OAuth 2.1 移除了不安全或不推荐的特性，如密码模式和隐式模式，强调 PKCE 的使用。
- 2021年：OAuth 2.1 正式成为标准，进一步完善了 OAuth 2.0 的规范，并统一了 OAuth 2.0 的实施和使用方法。
6. OAuth 2.1 的关键改进
- PKCE：OAuth 2.1 强制要求 PKCE 作为授权码模式的一部分，增加了安全性。
- 去除不推荐的模式：OAuth 2.1 去除了密码模式和隐式模式，推荐使用授权码模式和客户端凭证模式。
- 简化规范：将多个扩展和补充规范整合到核心标准中，简化了实现过程。
总结
OAuth 2.0 的历史演进经历了从 OAuth 1.0 的初步尝试到成为现代网络授权和身份验证标准的过程。通过简化授权流程、引入新的安全机制和扩展功能，OAuth 2.0 成为了广泛应用的授权框架。OAuth 2.1 的发布进一步提升了协议的安全性和易用性，为未来的网络应用提供了更强大的支持。
完。
五、一个秘密
希望对您有所帮助！关注锅总，及时获得更多花里胡哨的运维实用操作！
锅总个人博客
https://gentlewok.blog.csdn.net/
锅总微信公众号
