SPA / 后端的利弊安全架构

Question

我不是高级安全开发人员（还有什么新功能）

上下文：我有一个使用 authn/authz 机制的单体应用程序，该机制基于存储在 Angular 应用程序中的自定义 JWT 并经常刷新。有点家常。我一次打破我的单体一个模块。现在是关于如何处理安全性的问题。

我有：

• 多个角度应用程序
• 多个 Swing 应用程序
• multiple back（一个大单体和多个经典 Web 应用程序）

我想切换到 openid 连接。我可以：

1. 放置一个带有 oidc 插件的反向代理（nginx、kong、...），为后端创建一个虚拟保护域。
   • 从 SPA 的角度来看：
     • 通过 PKCE 使用代码授权流程
     • 当 SPA 向 RP 发送 http 请求时，RP 会检查 JWT，对其进行验证，如果无效/缺少标头，则发送 401。
     • SPA 将用户重定向到 Idp / 登录页面。
     • 现在我有点迷茫，需要上网查一下 :)：我不知道重定向 url 是什么（RP 还是 SPA？我假设只有 RP 代理在 Idp 中注册）
     • RP转发原始请求时，设置了header x-userinfo，后端只读取这个。
   • 对于背靠背通信，我们传播了收到的 x-userinfo 标头。
2. 没有反向代理，每个后端检查授权承载头，并在无效或丢失时重定向到授权服务器。每个后台管理安全问题（验证、重定向、注册）。

如您所见，我有很多误解。我的问题是：

1. 反向代理是个好主意吗？
   • 将 RP 与旧系统一起放置是否更容易（只需检查一个标头？）
   • 我们将 authz 逻辑放入 RP .... 嗯...
   • 我脑子里没有所有步骤（如何处理重定向）
2. 当 Swing 应用程序（已登录）想要将用户重定向到新功能 --> 打开浏览器窗口到 Angular 应用程序时，有没有办法处理安全性或者我需要让 Angular 应用程序处理这个问题（也许会强制用户重新登录 Idp 以获取 JWT 到其 cookie/localStorage 中？）。

谢谢

Answer 1

1a。重定向 URI 是 SPA 的 Web 来源，应该是您在浏览器中看到的内容。重定向总是发生在浏览器中（前端通道）。

2a。对于较新的组件，目标是zero trust architecture。在 OAuth 中，这仅意味着将 JWT 访问令牌传递给每个 API。旨在避免在标头中传递用于授权的敏感数据。

1b。反向代理对于您的 API 来说是一种极好的实践——正如IAM Primer 中所讨论的那样。不过，它可能对静态 Web 内容不太有用，因为您可能希望通过内容交付网络进行部署。

2b。每个应用程序都应该获得自己的令牌并重定向用户一次 - 通常是单点登录。 2021 年建议在 SPA 中使用安全 cookie，这些 cab 包含令牌。

一些通用的授权逻辑可以在 RP 中完成 - 这很酷。不过，真正的域特定授权应该在 API 中完成，使用 scopes 和 claims。

摘要

旨在遵循新组件的最佳做法。上面的 Curity 链接以 cab 适用于任何提供商的方式解释了这些。希望能给你一些有用的指导。