Pros/cons SPA/后端的安全架构
Pros/cons security architecture for SPA / Backend
我不是高级安全开发人员（还有什么新鲜事）
上下文： 我有一个整体使用 authn/authz 机制，基于存储在 angular 应用程序中的自定义 JWT，并经常刷新。有点自制。我一次打破了我的整体式模块。现在是关于如何处理安全问题。
我有：
- 多个 angular 应用程序
- 多个 Swing 应用程序
- 多回（一个大单体和多个经典网络应用程序）
我想切换到 openid 连接。我可以:
- 放置一个带有 oidc 插件的反向代理（nginx、kong、...），为后端创建一个虚拟保护域。
- 从 SPA 的角度来看：
- 使用 PKCE 的代码授权流程
- 当 SPA 向 RP 发送 http 请求时，RP 检查 JWT，验证它，如果 invalidate/missing header.
发送 401
- SPA 将用户重定向到 Idp/登录页面。
- 现在我有点迷路了，需要上网查查 :) : 我不知道什么是重定向 url（RP 还是 SPA？我假设只有 RP 代理是在 Idp 中注册）
- 当 RP 转发原始请求时，header x-userinfo 被设置，后端只读取这个。
- 为了背靠背通信，我们传播了收到的 x-userinfo header。
- 没有反向代理，每个后端检查授权承载 header 并在无效或丢失时重定向到授权服务器。每个后台管理安全问题（验证、重定向、注册）。
如你所见，我有很多误解。我的问题是：
- 反向代理是个好主意吗？
- 将 RP 与遗留系统放在一起是否更容易（只有一个 header 要检查？）
- 我们将 authz 逻辑放在 RP 中....嗯...
- 我脑子里没有所有步骤（如何处理重定向）
- 当 Swing 应用程序（已登录）想要将用户重定向到新功能时 --> 打开浏览器 window 到 angular 应用程序，有没有办法处理安全性还是我需要让 angular 应用程序处理这个问题（并可能强制用户重新登录 Idp 以在其 cookie/localStorage 中获取 JWT？）。
谢谢
1a。重定向 URI 是 SPA 的 Web 来源，应该是您在浏览器中看到的内容。重定向总是发生在浏览器中（前端通道）。
2a。对于较新的组件，目标是 zero trust architecture。在 OAuth 中，这只是意味着将 JWT 访问令牌传递给每个 API。旨在避免在 headers.
中传递用于授权的敏感数据
1b。反向代理对您的 API 来说是一种很好的做法 - 正如本 IAM Primer 中所讨论的那样。不过，它对于静态 Web 内容可能用处不大，因为您可能希望通过内容分发网络部署它。
2b。每个应用程序都应该获得自己的令牌并重定向用户一次——通常是单点登录。 2021 年建议在 SPA 中使用安全 cookie，这些 cab 包含令牌。
一些通用的授权逻辑可以在 RP 中完成 - 这很酷。不过，真正的域特定授权应该在 API 秒内完成，使用 scopes and claims.
摘要
旨在遵循更新组件的最佳做法。上面的 Curity 链接以 cab 适用于任何提供商的方式解释了这些内容。希望它能给你一些有用的指示。
我不是高级安全开发人员（还有什么新鲜事）
上下文： 我有一个整体使用 authn/authz 机制，基于存储在 angular 应用程序中的自定义 JWT，并经常刷新。有点自制。我一次打破了我的整体式模块。现在是关于如何处理安全问题。
我有：
- 多个 angular 应用程序
- 多个 Swing 应用程序
- 多回（一个大单体和多个经典网络应用程序）
我想切换到 openid 连接。我可以:
- 放置一个带有 oidc 插件的反向代理（nginx、kong、...），为后端创建一个虚拟保护域。
- 从 SPA 的角度来看：
- 使用 PKCE 的代码授权流程
- 当 SPA 向 RP 发送 http 请求时，RP 检查 JWT，验证它，如果 invalidate/missing header. 发送 401
- SPA 将用户重定向到 Idp/登录页面。
- 现在我有点迷路了，需要上网查查 :) : 我不知道什么是重定向 url（RP 还是 SPA？我假设只有 RP 代理是在 Idp 中注册）
- 当 RP 转发原始请求时，header x-userinfo 被设置，后端只读取这个。
- 为了背靠背通信，我们传播了收到的 x-userinfo header。
- 从 SPA 的角度来看：
- 没有反向代理，每个后端检查授权承载 header 并在无效或丢失时重定向到授权服务器。每个后台管理安全问题（验证、重定向、注册）。
如你所见，我有很多误解。我的问题是：
- 反向代理是个好主意吗？
- 将 RP 与遗留系统放在一起是否更容易（只有一个 header 要检查？）
- 我们将 authz 逻辑放在 RP 中....嗯...
- 我脑子里没有所有步骤（如何处理重定向）
- 当 Swing 应用程序（已登录）想要将用户重定向到新功能时 --> 打开浏览器 window 到 angular 应用程序，有没有办法处理安全性还是我需要让 angular 应用程序处理这个问题（并可能强制用户重新登录 Idp 以在其 cookie/localStorage 中获取 JWT？）。
谢谢
1a。重定向 URI 是 SPA 的 Web 来源，应该是您在浏览器中看到的内容。重定向总是发生在浏览器中（前端通道）。
2a。对于较新的组件，目标是 zero trust architecture。在 OAuth 中，这只是意味着将 JWT 访问令牌传递给每个 API。旨在避免在 headers.
中传递用于授权的敏感数据1b。反向代理对您的 API 来说是一种很好的做法 - 正如本 IAM Primer 中所讨论的那样。不过，它对于静态 Web 内容可能用处不大，因为您可能希望通过内容分发网络部署它。
2b。每个应用程序都应该获得自己的令牌并重定向用户一次——通常是单点登录。 2021 年建议在 SPA 中使用安全 cookie，这些 cab 包含令牌。
一些通用的授权逻辑可以在 RP 中完成 - 这很酷。不过，真正的域特定授权应该在 API 秒内完成，使用 scopes and claims.
摘要
旨在遵循更新组件的最佳做法。上面的 Curity 链接以 cab 适用于任何提供商的方式解释了这些内容。希望它能给你一些有用的指示。