你可能已经见过那些“使用 Google 登录”或“连接 GitHub”的按钮，这些按钮让你无需输入新的凭证就能登录并访问不同的服务。无论是使用社交媒体账户登录网站，还是授权第三方应用与您的电子邮件互动，OAuth 2.0 都是这一过程背后的协议。

本文将解释为什么 OAuth 2.0 是必不可少的，它的核心组件、授权过程、最佳实践、常见用例，以及为不同场景设计的各种流程。

那么，让我们开始吧。

Catio：您的技术架构副驾驶（赞助）

通过 Catio 解锁更智能的技术栈决策潜力。获得实时可观测性、全天候 AI 驱动的建议，以及为您的架构量身定制的设计模式，以自信地构建弹性和可扩展的技术栈。无论您是在设计 OAuth 2.0 还是实施其他设计模式，Catio 都能在架构生命周期的每个阶段帮助您的团队做出数据支持的决策。

准备好利用 AI 专业知识来架构并提升您的技术栈了吗？

在 Catio.tech 了解更多

我们都记得，当我们需要登录每个使用的网站或服务时，这意味着我们需要知道每一个的密码。随着网络服务的整合，它们开始请求用户的其他服务凭证以访问关键数据。 这种做法在安全性方面是危险的。

然后， OAuth 被引入来解决这个问题。它试图通过允许服务 A 在不需要您的服务 B 凭证的情况下，安全地访问您在服务 B 上的信息来解决这个问题。

通过 OAuth ，您的食品配送服务可以访问您的社交媒体，或者您的 Facebook 账户可以访问您的联系人。关键是所有这些授权都在我们的控制之下。

为什么我们需要 OAuth 2.0 协议？

实际上，OAuth 2.0 简化了用户体验，同时保持了安全性。当您看到“使用 Google 登录”或“连接 Facebook”这样的选项时，您就看到了 OAuth 的实际应用。

以下是它如何工作的快速概述：

1. 您将一个应用程序（客户端）连接到一个服务（资源服务器）。

2. 服务请求您的许可，说明应用程序想要访问的内容。

3. 如果您同意，服务会给应用程序一个唯一的密钥（访问令牌）。

4. 应用程序使用此令牌在您批准的限制范围内访问服务上的数据。

此过程允许应用程序在不知晓您的密码的情况下代表您进行交互。

什么是 OAuth 2.0？

OAuth 2.0 是一个授权框架，提供对资源的安全委托访问。它使用 令牌 来授予从一个站点（资源服务器）到另一个站点（客户端）的用户数据的有限访问，而不是共享凭证。

该框架定义了四个 角色 ：

• 💻 客户端 ：请求访问资源的应用程序。

• 🔑 资源所有者： 可以授予或拒绝访问其数据的用户。

• 🛡️ 授权服务器 ：向客户端发放访问令牌的服务器（例如： accounts.google.com ）。

• 🖥️ 资源服务器： 托管受保护资源的服务器（它可以与授权服务器相同）。

它包括以下 资源 ：

• 📜 授权许可 ：证明用户已授予权限的令牌或代码。

• 🔄 重定向 URI ：用户在认证后被重定向的 URL，也称为回调（例如： yourwebsite.com/callback ）。

• 🔑 访问令牌 ：客户端在获得许可后访问数据的密钥。

过程 通常如下（ 抽象协议流程 ）：

1. 用户想要访问应用程序中的一些资源

2. 应用程序请求授权

3. 用户输入凭证

4. 应用程序将凭证与 OAuth 密钥一起传输到授权服务器

5. 授权服务器返回访问令牌

6. 应用程序将访问令牌发送到资源服务器

7. 资源服务器向应用程序提供资源

8. 应用程序向用户返回信息，表明应用程序可访问

OAuth 2.0 流程

OAuth 2.0 定义了几种授权类型，每种类型适用于不同的场景：

1. 🌐 授权码流程 ：用于网页和移动应用。这是最常见的流程，通过获取授权码来交换访问令牌，确保客户端不会将令牌暴露给用户代理。

2. 🖥️ 客户端凭证 ：用于服务器间的身份验证，客户端可以使用其凭证而不是模拟用户来获取访问令牌。

3. 📱 设备码 ：用于输入能力有限的设备。

4. ⚠️ 隐式流程 ：以前用于客户端应用如单页应用（SPA），在授权后直接返回访问令牌，但缺乏刷新令牌，因安全问题不再推荐。它在 OAuth 2.1 中 已被弃用 。

5. 👤 资源所有者密码凭证 ：此流程允许客户端直接使用资源所有者的用户名和密码。适用于高度信任或遗留应用，但 因安全风险不推荐使用 。

➡️ 我们如何决定使用哪种流程？

• 如果请求方是机器而不是人，在机器对机器的授权中，我们可以使用 客户端凭证流程 。

• 如果客户端在服务器上执行网页应用，我们应使用 授权码流程 。

• 对于原生移动应用的特殊情况，我们应使用 带有代码交换证明（PKCE）的授权码流程 。

此外，OAuth 2.0 中使用了以下 令牌 ：

• 🔑 访问令牌 ：用于访问受保护资源的短期令牌。

• ♻️ 刷新令牌 ：用于获取新访问令牌的长期令牌。

• 🆔 ID 令牌 ：包含关于终端用户身份验证的声明（特定于 OpenID Connect）。

OAuth 2.0 实施

在实施 OAuth 2.0 时，我们应采取以下步骤：

1. 注册您的应用 ：从授权服务器获取客户端凭证。

2. 选择合适的流程 ：根据您的应用类型和需求选择。

3. 实施所选流程 ：遵循 OAuth 2.0 规范实施所选的授权类型。

4. 安全地处理和存储令牌 ：实施适当的令牌管理。

5. 验证令牌 ：在信任令牌之前始终验证收到的令牌。

6. 实施令牌刷新 ：使用刷新令牌来维持长期访问。

授权码流程 🔒

授权码授权类型是最常见的，因为它最适合源代码不公开的服务器端应用，并且可以保持 客户端密钥 的机密性。这是一个 基于重定向的流程 ，这意味着应用必须能够与用户代理（用户的网页浏览器）连接，并通过它接收 API 权限代码。

我们应为 网页和移动应用 使用授权码流程。它通过交换授权码增加了一层安全性。

授权码流程 的实现过程如下：

1. 客户端通过将用户重定向到 授权服务器 来启动流程。

   

   以下是每个查询参数的解释：

   • response_type=code - 这告诉授权服务器应用程序正在启动授权码流程。在授权码流程中，总是设置为“code”。

   • client_id - 您的应用程序的唯一标识符，是开发者首次注册时获得的。它告诉授权服务器哪个应用程序正在发出请求。

   • redirect_uri - 用户授权后应被发送到的URL。

   • scope - 您的应用程序请求的权限列表，以空格分隔。它定义了您的应用程序请求的访问权限。例如， scope=read_user write_posts 。

   • state - 您的应用程序生成的随机字符串，并在请求中包含。然后应检查在用户授权应用程序后返回的值是否与之相同。这用于防止 CSRF攻击 。

2. 用户 授权 客户端（一个示例）。

   

3. 如果客户端批准代码， 授权服务器 会将用户重定向回客户端，并附带授权码。 state 值与应用程序最初在请求中设置的相同，并由授权服务器生成授权码。

   

4. 现在，客户端通过POST请求将 授权码 交换为 访问令牌 。

   

5. 授权服务器响应一个 访问令牌 （以及可选的刷新令牌）。

   

6. 现在，客户端可以执行最初想要的操作：访问 资源服务器 ，这将由于请求中附带的 访问令牌 而被允许。

这里的情况是，客户端想要访问其无权访问的资源。资源服务器将不允许这种访问，因此我们在 OAuth 中引入了 范围（scope） 的概念。

⚠️ 请注意，我们应该始终使用 PKCE（Proof Key for Code Exchange） 来增强安全性，尤其是在移动应用中。在一般的授权流程中，攻击者可能会拦截发送给客户端的授权码并将其兑换为访问令牌，这意味着攻击者可以代表我们访问资源。这通常是通过在用户设备上注册恶意应用来实现的。因此，PKCE 通过引入新的流程和参数来解决此安全问题：代码验证器（Code Verifier，一个随机字符串）、代码挑战（Code Challenge）和代码挑战方法（Code Challenge Method）。这些附加参数共同作用，将授权请求安全地绑定到发起请求的客户端。通过在令牌交换期间要求代码验证器，PKCE 确保即使攻击者拦截了授权码，他们也无法在没有正确代码验证器的情况下将其兑换为访问令牌。了解更多信息请点击 这里 。

刷新令牌流程 🔄

当访问令牌过期时，尝试从 API 发起调用将返回无效令牌错误。如果在初始访问令牌发放时同时发放了刷新令牌，则可以使用该刷新令牌向授权服务器请求新的访问令牌。

刷新令牌流程的工作原理如下：

1. 客户端检测到访问令牌已过期。

2. 客户端使用刷新令牌向令牌端点发送请求

以下是使用刷新令牌获取新访问令牌的 POST 请求示例：

授权服务器验证刷新令牌并发放新的访问令牌：

OAuth 2.0 使用案例

以下是一些常见的 OAuth 2.0 使用 案例 ：

案例 1：第三方访问 🔗

用户可以授予第三方应用有限的资源访问权限，而无需共享他们的凭据，例如允许照片打印服务访问存储在云服务中的照片。

例如 ，用户允许一个日程安排应用访问他们的 Google 日历，以便自动设置会议，而无需共享他们的 Google 凭据。

案例 2：单点登录（SSO）🔑

它促进了单点登录（SSO），用户可以使用单一 ID 登录多个服务，从而简化跨平台和服务的身份验证过程。

阅读更多关于 SSO 的信息：

Tech World With Milan Newsletter单点登录（SSO）如何工作？在本期中，我们将讨论单点登录（SSO）。通过单一的登录凭证，用户可以安全地访问多个应用和服务，这要归功于SSO这一用户认证机制……阅读更多6个月前 · 36个赞 · 5条评论 · Dr Milan Milanović

例如 ，一名员工登录到他们的公司网络后，可以访问不同部门的应用程序，如电子邮件、人力资源系统和项目管理工具，而无需再次登录。

用例3：移动应用 📱

OAuth 2.0为移动应用提供了一个框架，以获取访问受保护资源所需的令牌，确保操作安全。

例如 ，用户下载了一款健身应用，该应用在通过OAuth 2.0授权后，可以访问用户的Spotify播放列表，在锻炼时播放音乐，而无需单独登录。

以及 最常见的OAuth提供者列表 。

OAuth 2.0最佳实践

在将OAuth 2.0集成到我们的应用工作流中时，我们应考虑以下最佳实践：

• 使用成熟的库 ：不要从头开始实现OAuth 2.0；使用维护良好的库。

• 使用短期 访问令牌 ：限制访问令牌的生命周期有助于减轻其被黑客攻击时的危害。您可以使用刷新令牌来获取新的访问令牌，而无需联系用户。

• 使用HTTPS ：在所有OAuth 2.0交互中始终使用TLS。

• 保密 ：永远不要在客户端代码中暴露客户端密钥或令牌。

• 使用 PKCE ：实施代码交换的证明密钥，以防止CSRF和授权代码注入攻击。

• 限制令牌范围 ：仅请求您的应用程序所需的权限（最小范围）。

• 优雅地处理错误 ：按照OAuth 2.0规范定义的方式实现适当的错误处理。

OAuth 2.0的缺点

以下是您在处理OAuth 2.0时可能遇到的一些问题

问题1：OAuth很复杂 🔄

使用此协议也有一些 缺点 。首先，对于不熟悉其概念和流程的开发人员来说，实施OAuth 2.0可能会很 复杂 ，因为它是一个庞大的标准。

在 官方网站 上，您可以找到超过17个RFC和 72个参数 ，定义了OAuth 2.0的工作原理。这通常导致团队仅为特定场景实施OAuth 2.0的最低要求。

问题2：协议误用 🚫

其次，虽然OAuth 2.0是为授权设计的，但有时被 误认为是认证 协议，而事实并非如此。这种误解可能导致错误的实现和安全风险。

OAuth 2.0旨在授予应用程序对用户在另一个系统上的资源的有限访问权限，而无需共享用户的凭证。它回答的是“这个应用程序被允许代表用户做什么？”而不是“这个用户是谁？”因此，它不知道谁刚刚用他们的电子邮件登录。

OpenID Connect 是为了解决认证需求而在OAuth 2.0的授权功能之上开发的。它是一个身份层，建立在OAuth 2.0之上。它使用ID令牌（以JWT — JSON Web Token的形式）和一些使用信息，提供标准化的用户认证方式和获取基本的个人信息。如果我们连接到支持OpenID Connect的授权服务器，我们可以请求访问令牌、ID令牌以及在/UserInfo端点上的所有信息。

问题3：实现不一致 ⚠️

此外，规范留有解释空间， 导致不同服务提供商之间的实现不一致 ，这可能导致互操作性问题。

在第一种情况下， 每个人在实际使用中都不同。 例如，一些API在授权调用中使用不同的参数， 取决于所需的内容 和他们希望在令牌请求调用中看到的内容。

在第二种情况下，我们看到 不同的非标准扩展被添加到OAuth中 。例如，您可能需要在 access_token 之外添加一些数据，以便能够与API一起工作。

我能为您提供的更多帮助

1. LinkedIn内容创作者大师班 ✨ 。 在这个大师班中，我分享了在科技领域扩大您在LinkedIn上的影响力的策略。您将学习如何定义目标受众，掌握LinkedIn算法，使用我的写作系统创建有影响力的内容，并制定推动显著成果的内容策略。

2. 简历现实检查 🚀 。我现在可以为您提供一项新服务，我将从CTO的角度审查您的简历和LinkedIn个人资料，提供即时、诚实的反馈。您将发现哪些内容突出，哪些需要改进，以及招聘人员和工程经理在第一眼看到您的简历时的看法。

3. 向35,000+订阅者推广自己 ，通过赞助本新闻通讯。此新闻通讯将您置于许多工程领导者和高级工程师面前，他们影响技术决策和采购。

4. 加入我的Patreon社区 ：这是您支持我、表示“感谢”的方式，并获得更多福利。您将获得独家福利，包括我所有关于设计模式、设定优先级等的书籍和模板，价值100美元，提前访问我的内容，内部新闻，有用的资源和工具，优先支持，以及影响我工作的可能性。

5. 1:1辅导： 与我预约工作会议 。1:1辅导可用于个人和组织/团队成长主题。我帮助您成为高绩效的领导者和工程师 🚀。

订阅Tech World With Milan Newsletter以投票

只有订阅者可以投票。

已经是订阅者？ 登录

投票

您对今天的新闻通讯有何看法？

很棒

还可以

没什么特别的

剩余5天

感谢您阅读Tech World With Milan Newsletter！免费订阅以接收新帖子并支持我的工作。