欢迎来到公海710 使用 OAuth 2.0 和 OIDC 的现代身份验证概述

现代身份验证通常不是单一解决方案，而是一组确定行业最佳实践的现代、普遍接受的标准和协议。

这些标准包括安全断言标记语言 (SAML)、网络服务联合（WS-Federation 或 WS-Fed）、OAuth 2.0 或 Open ID Connect (OIDC) 等协议。这些协议和标准已经取代了安全性较低的传统身份验证模型。出于本博客的目的，主要重点将放在 OAuth 2.0 和 OIDC – 下面将详细讨论其中的每一个。

除了从传统身份验证模型向现代身份验证模型的转变之外，还采用了“零信任”模型。该模型的开发是为了管理分布式劳动力的范式——结合了不断增长的云采用和越来越多的远程工作人员。该模型将在下面的部分中详细讨论。

这提供了身份验证模型“理想状态”的视角 - 只是奠定了可以与现有状态进行比较的框架。与任何理想状态一样，并不期望每个组件或元素都完全遵守或完全实现。

在本现代身份验证文档中，可能会引用利用这些规范的特定技术（例如 Microsoft、Okta）。本文档的目的并不是提倡或偏爱一种技术而不是另一种技术，而是提供开放标准的具体示例。由于现代身份验证被定义为一组开放标准，因此实施实体切换 IdP 的能力应该接近无摩擦。

最后，这并不是现代身份验证所有细节的综合指南。相反，它应该为现代身份验证及其核心组件奠定基础。

OAuth 2.0

OAuth 2.0 规范利用一系列流程来实现信任和身份验证。这些流程各自具有不同的目的，旨在创建标准化的系统管理方法。默认流程（授权代码流程）的设计方式使受信任的应用程序可以验证用户凭据及其自己的凭据以代表用户执行操作。此过程首先向 IdP 请求身份，要求用户验证自己。此过程可能会利用来自用户的一条或多条信息，例如他们知道的信息（密码、安全问题）、他们拥有的信息（短信、电子邮件）或他们的信息（生物识别信息）。一旦满足此身份要求，IdP 将向 Web 应用程序返回授权代码。然后，Web 应用程序将此代码及其凭据发送回 IdP，以获取可用于后续请求的令牌（JWT 形式）。在下图的情况下，Okta 充当 IdP – 但对于任何实现授权代码流规范的提供商来说，流程都是相同的。

图 1：Okta 授权代码流程 (来源)

授权代码流设计用于受信任的网络应用，其中网络应用与授权服务器 (IdP) 之间的请求受到保护。然而，并非所有应用程序都是如此，因为 JavaScript 单页应用程序或移动应用程序将要求通过潜在不受信任的网络发送此请求 - 在这两种情况下，该网络都由用户使用。在使用这些场景时，建议使用带有 PKCE 的授权代码流。

代码交换证明密钥 (PKCE) 是一个涉及为每个授权请求生成唯一密钥的过程。这有助于确保提供的授权代码与原始 Web 应用程序请求匹配。通过生成代码然后对代码进行哈希处理，可以将哈希值与原始授权代码请求一起发送到授权服务器。当客户端（而不是 Web 应用程序）现在使用所提供的授权代码请求代码时，它可以发送该密钥的明确（未散列）值，然后授权服务器可以对该请求进行散列并验证该请求。

图 2：使用 PKCE 的 Okta 授权代码流程 (来源)

在机器对机器 (M2M) 通信的情况下，无需考虑最终用户，OAuth 设计了客户端凭据流程。  此流程直接请求/令牌具有客户端凭据的端点。这只应在两个系统都是自动化且位于受信任或已知网络上的情况下完成。

图 3：Microsoft 客户端凭据流程 (来源)

隐式流程 - 除非有必要，否则应避免，因为客户端机密的机密性不能有保证。此流程通常不支持任何形式的刷新令牌，并且是为不支持现代加密技术的旧版浏览器设计的。

虽然不同的 IdP 可能会为特殊目的解决方案实施额外的流程，但此处记录的流程应该为理解 OAuth 2.0 结构提供良好的基础。作为某些流程的一部分，可以请求并提供可选的刷新令牌。刷新令牌可以发送到/令牌直接端点，连同客户端信息一起获取新令牌。这允许用户重新创建或维护会话，而无需再次提示验证。刷新令牌应像密码一样对待，因为它们允许应用程序代表经过验证的用户执行操作。

由于选择流的决策可能很复杂，下图显示了一个简化的决策树，可用于选择适当的流。这是由 Okta 提供的，但该概念应适用于考虑不同的 IdP（例如 Microsoft）。

图 4：OAuth 流程决策树 (来源)

IdP 将实现两个主要端点：/授权和/令牌。/授权端点将负责验证用户身份并生成授权代码。 /token 端点将采用授权代码和客户端凭据（由 IdP 提供给 Web 应用程序或客户端应用程序的凭据）进行验证。如果提供了有效的凭据，则/令牌端点将创建一个 JWT，该 JWT 可以提供回网络或客户端应用程序以在授权标头中使用。该令牌是授权规范中定义的“承载”令牌。

向 请求授权码时/授权端点，OAuth 规范包括用户必须同意的范围列表作为请求的一部分。这些范围基本上是 Web 或客户端应用程序的授权组件。根据 IdP 配置，用户可能必须与对话框交互才能同意其中一个或多个范围，因此可以提供授权代码。

OpenID Connect (OIDC)

OIDC 构建于 OAuth 2.0 之上，旨在通过称为“id 令牌”的第二个令牌来扩展 OAuth 的功能。一些范围模型在 OIDC 规范中进行了标准化，但 OIDC 的主要目的是启用包含用户核心信息的联合身份。考虑 OIDC 的最佳方式是网站上可能显示的“使用 Facebook 登录”或“使用 Google 登录”按钮。选择此按钮后，Web 或客户端应用程序将向相应的 IdP 发送请求，当用户与该 IdP 建立会话（如果还没有会话）时，系统将提示他们允许客户端或 Web 应用程序访问信息，例如电子邮件地址、姓名、地址等。当这些请求获得批准时，IdP（Facebook 或 Google）会将授权代码发送回应用程序，就像正常流程一样。当应用程序将请求发送到 _/token_endpoint 时，会向它们提供访问令牌和 id 令牌。访问令牌与授权标头一起用作承载令牌，而 id 令牌包含 IdP 验证的有关用户的声明，例如姓名、电子邮件或其他信息。

重要的是要了解，对 OIDC 的支持是对 OAuth2.0 的补充，而不是排除它。每当本文档引用现代身份验证时，它都会引用 OAuth 2.0 和 OIDC 模型的组合支持。

零信任架构

零信任或零信任架构是现代技术领域处理网络安全的现代范例。它不是识别更静态的、受网络限制的（基于网络的）边界，而是关注更细粒度的资产和用户集。该模型只是指出，不存在仅基于物理或网络位置或所有权授予的隐式信任。

传统信任架构可以比作城堡。城堡有高墙、护城河和有限的进入点——然而，一旦进入城堡，就不会进行任何确认、验证或检查来授予访问权限。这代表了一个企业内部网，其中的资源可能具有最低限度的安全性或没有安全性，而是依赖网络边界来验证访问。现代零信任架构更像是封闭的社区。与企业网络一样，社区已经控制了入口点和检查，但是，访问社区内的每个房屋也需要适当的访问、控制和检查。在零信任架构中，每个应用程序（充当服务提供商）都要求在授予访问权限之前提供正确的凭据（访问令牌）。

此模型专为现代应用和工作世界而设计，在这个世界中，软件即服务盛行，云集成也很常见。这对于现代劳动力来说尤其重要，因为远程工作人员已成为常态，而企业 VPN 和连接不足以防止数据泄露。黑客利用的最常见的违规模式之一（称为特权升级）是从用户那里获取凭据，然后在内网内部并行，直到他们可以获得更多特权的凭据。重复此过程，直到他们到达网络边界的内部并可以访问网络和公司资源。零信任架构以及最低权限模型旨在帮助减少或限制攻击面。 

类似模型

为了更好地理解这一点，提供了以下类比。它绝不是完美的，但它应该有助于建立现代身份验证的心理模型。

想象一下美国驾驶执照的情况。该执照由国家控制并由控制实体颁发。就许可证甚至身份证而言，国家充当 IdP——确定持有者的身份。当许可证被提交给另一个服务提供商（例如一家餐馆）时，国家和餐馆之间就存在一种隐含的信任，即所提供的身份证或许可证包含有关提交者的有效声明（信息）。姓名、年龄和地址等信息是卡上固有的声明，而图片和州印章则验证出示的用户与用户声明相符，并且州政府已验证该信息。国家不负责如何服务提供商（餐馆、酒吧、汽车经销店等）使用该信息，只要该信息真实准确即可。这是现代身份验证中 IdP/SP 关系数字概念的物理模型。

结论

这只是众所周知的信息冰山一角；无论您处于现代身份验证之旅的哪个阶段，我们都会随时为您提供帮助 - 从开始您的第一个项目到故障排除或扩展您的现有系统。