使用 OAuth 实现大型网站现代化的 5 个步骤

云云众生s

发布于 2024-03-27 18:28:53

820

发布于 2024-03-27 18:28:53

文章被收录于专栏：云云众生s云云众生s

使用 OAuth 实现大型网站现代化的 5 个步骤

本文翻译自 5 Steps to Modernize Large Websites using OAuth 。链接可以查看原文。

概述了在为 Web 和 API 组件实施安全解决方案时推荐的一些部署和分离模式。

软件系统的主要关注点之一是随着逻辑量的增长，保持代码库的可维护性。

近年来，将代码分解为模块化组件已成为最佳实践：微服务和微 UI。然后，每个组件都可以由并行工作的不同开发团队管理，而不会相互影响。每个团队都可以按照自己的节奏运作，并且更容易地使他们的工具、技术和能力保持最新。所有这些都会导致更快、更具可扩展性的业务交付。

然而，许多现有的现实世界商业平台并不是这样构建的。相反，它们是以较旧的网站架构风格制作的。大约十年前，这些代码库变得非常庞大且难以管理是很常见的，从而减慢了业务交付速度。

对于仍在运营大型网站的公司，通常迫切需要对系统进行现代化改造以实现微服务的上述优势。然而，并不总是很清楚要做出哪些部署和安全选择，或者如何迁移现有的基于 cookie 的安全性。

在这里，我将概述我们在 Curity 为 Web 和 API 组件实施安全解决方案时推荐的一些部署和分离模式。这些技术也非常适合对大型网站的架构进行现代化改造。

基础：OAuth 和 OpenID Connect

现代应用程序级组件使用 OAuth 系列规范实现安全性，它为 Web 应用程序、移动应用程序和 API 提供安全功能。这为公司提供了最先进的选择，可以使用一种或多种身份证明来验证用户。它还有助于根据业务规则保护 API 中的数据。

在这篇文章中，我不会详细介绍安全标准。相反，我将专注于高级技术和文化步骤，以帮助将大型网站分解为更小的部分。这个可管理的过程将避免大爆炸的方法来确保业务连续性。

我还将假设组织从一个大型网站开始，该网站以基本方式使用基于 OAuth 的登录和安全 cookie，但没有充分利用该架构。

初始网站架构

考虑以下处理保险业务逻辑的大型网站示例。本网站使用较旧的 .NET 框架并部署到 Windows 服务器。许多网页都是通过 HTML 和数据的组合后下载到浏览器的。较新的代码越来越多地使用 Ajax 请求来更新页面并使它们感觉快速和交互。 Web 后端还必须管理许多 API 路由。

开发人员可能知道如何将大型代码库重构为多个应用程序。但是，这样做还需要更改 Web 后端的部署和 cookie 安全性。这可能让人望而生畏，因为它可能需要运营团队的支持，并导致用户体验问题，例如每个应用程序需要单独登录。企业还可能担心正在进行的、通常是高优先级的业务目标的影响。

因此，在接下来的部分中，我提出了一种管理渐进式现代化的安全方法，该方法包括五个主要步骤。

第 1 步：使用 API 网关入口点

现代化过程的第一步应该是引入反向代理或 API 网关。这可以用在很多安全设计模式中，对于拆分网站也很有效。

在下图中，从示例保险业务领域中选择了一个不太复杂的业务领域（营销）。营销应用程序已拆分为自己的网站。一个高性能的网关，如 NGINX，然后成为 Web 入口点，形成以下端到端的流程：

此重构将涉及一些适度的代码更改，并且应该仅使用“提升和转移”迁移，因为它主要是一项部署工作。在这个阶段，新的营销网站应该继续使用与主网站相同的.NET 框架技术。

请务必记住，每个网站都必须配置为使用相同的 cookie 属性，包括 cookie 名称和加密密钥。这将使用户能够登录其中一个应用程序，然后无缝导航到另一个应用程序。如果使用 OAuth，那么两个网站将使用相同的 OAuth 客户端，每个网站包含不同的重定向 URI（回复 URL）。一些例子：

这将需要进行一些部署和 cookie 调查，并且您需要确保网站继续向浏览器返回外部 URL。

完成后，营销网站将分配给一个特定的团队，该团队将成为其组件所有者。然后，他们在更小、更易于管理的代码库上工作。未来，公司可以在其他业务领域采用相同的方法，因此已经有了一个将整个网站模块化的流程。

第 2 步：分离 Web 和 API 问题

自从将应用程序构建为网站以来，技术一直在发展。公司通常希望使用诸如 React 之类的框架，开发人员可以在其中编写仅关注前端的代码，并专注于提供最佳的客户体验。这对商业领袖很有效，因为他们通常不希望 Web 开发人员处理 Web 后端管道。

因此，团队和企业主可能同意将在上一步中模块化的营销网站更新为单页应用程序 (SPA) 架构。一个主要工作领域将涉及将数据逻辑从 Web 后端的 Ajax 端点迁移到 API。另一个将更改 UI 以使用客户端渲染，而不是在后端将 HTML 与数据结合：

迁移可以逐步且安全地完成，一次迁移几页，而整个应用程序仍然是一个网站。这将使您避免“大爆炸”升级。这些 API 迁移还将提供短期代码共享优势，例如使网站功能能够被移动应用程序重用。

但是，要积极进取并以完成迁移为目标，因为这是实现您喜欢的架构的先决条件。选择一个也适合业务的时间，例如当营销应用程序没有其他重要的前端优先事项时。尽早迁移一些困难的页面，并记录分步过程。

在技术方面，旨在使其成为“提升和转移”操作，您可以在其中尽可能多地移动现有代码。由于重点是分离，因此避免将更新到 React 等 Web 框架作为这项工作的一部分，以防止技术风险。考虑将前端保持在纯 JavaScript 中，使用像 mustache.js 这样的简单库进行客户端渲染。

第 3 步：集成单页应用程序安全性

将网站迁移到 SPA 的棘手领域之一是安全性。在浏览器中使用令牌会打开更多的攻击媒介，您必须防范跨站点脚本 (XSS) 威胁。当前的 SPA 安全最佳实践是继续以与网站相同的方式使用 HTTP-only cookie。因此 SPA 需要应用程序级 cookie 层。

对于受 OAuth 保护的 SPA，集成 cookie 的最主流方式是通过前端定制后端 (BFF)。网关还用于将静态内容请求与 OAuth 和 API 请求分开。这样做可以实现最佳的用户和开发人员体验，同时还可以确保您可以将 SPA 作为静态内容部署到您选择的任何主机。

在 Curity，我们推荐一种 API 驱动的 BFF 变体，称为令牌处理程序模式。这涉及插入经过测试的组件来处理 OAuth 和 cookie，避免向您的应用程序代码添加安全管道的需要。在以下流程中，OAuth Agent 代表 SPA 调用授权服务器并发布 cookie。 OAuth 代理是一个网关插件，它在 API 请求期间进行特定于 Web 的安全检查，然后将 JWT 访问令牌转发到目标 API：

对于较新的 SPA，颁发的访问令牌应使用最小特权原则设计。保持访问令牌的生命周期短，并使用 scopes 和 claims 将其锁定。这确保了颁发给营销应用程序的访问令牌只能发送到营销 API，然后营销 API 可以使用令牌的 scopes 和 claims 进行授权。这是一种比大型网站使用的设计更安全的设计，这些大型网站的 cookie 授予对许多业务领域的访问权限。

在此阶段，可能会有一个学习曲线，因此请计划一些峰值以降低它的风险。首先，使用小型概念验证 (POC) 应用程序部署新组件。此外，确保 API 进行与之前网站相同的授权检查。查看这些 API 指南，了解有关基于 claims 授权的使用 JWT 访问令牌的更多详细信息。

第 4 步：混搭 Web 样式

对大型网站进行现代化改造需要时间，但此处提出的方法可让您在其他业务目标之间逐步实现。在此期间，网关允许您混合和匹配 Web 架构样式，并在需要时将它们暴露在相同的基本 URL 上。

将较新的 SPA 与现有大型网站集成时，请使用单点登录 (SSO)，这样 SPA cookie 就不会与网站共享。然后，每个新应用程序都会获得自己的最低权限令牌，从而实现最佳安全性。它还使您能够为不同的用户组改变身份验证，例如使用较新的无密码设备登录某些应用程序。

在此示例中，我们可以看到熟悉的营销应用程序和主网站。他们加入了一个新添加的广告应用程序，该应用程序具有不同的风格，因为它返回不安全的数据并且需要实现良好的搜索引擎优化 (SEO)。因此，此应用程序继续使用服务器端呈现 (SSR) 来同时返回 HTML 和公共数据。它可以暴露在不需要 cookie 的网关路径上。