我的问题相当复杂，我不知道我们目前的做法是否正确。
首先对系统进行概述：
我们有多个“服务”（所有 Web 应用程序，如 React、Streamlit、Vue 等），每个服务都由不同的团队开发。我们现在希望通过单个页面为客户提供对这些服务的访问，每个客户在该页面上只能访问部分服务。这些服务应嵌入到主页上的 iframe 中。目标是在不改变所有服务的情况下完成这一切。
我们当前的解决方案现在使用具有子请求身份验证的反向代理。我们使用 jwt 来验证对后端的所有调用。现在，当前端请求服务时，我们包含 jwt 标头，反向代理使用转发的标头向后端发出子请求，并询问是否允许用户访问该服务。这适用于简单的 html 页面，但是如果服务的前端自己执行任何请求，则会失败，因为在请求中显然缺少 jwt 标头。
有没有办法将标头添加到服务从 iframe 内部发出的所有请求中？
或者我们的方法不好，这个任务有更好的解决方案吗？
最好的解决方法是分离 Web 和 API 问题。例如，使用这样的路由，其中只有第二条路由需要访问令牌：
https://www.product1.com
https://www.product1.com/api
网络导航请求
如果网络资源只是静态内容，那么您不需要发送访问令牌，因为用户正在下载不安全的静态资源。然后，用户可以在应用程序之间导航，不会因缺少令牌而出现任何问题。
API 请求
如果您在与用于静态内容的路由分开的路由上发出所有 API 请求，则 JavaScript 始终可以附加授权标头，因此发送访问令牌是可靠的。
WEB HTML + 数据响应
如果您在 HTML 响应中返回安全数据，则该数据将需要保护，因此上述方法无效。在这种情况下，您将需要前端应用程序将 cookie 凭据发送到后端，以便确保上述两种类型的请求的安全。
浏览器安全
事实上，现在建议避免在浏览器中使用令牌，并使用
HTTP-only SameSite=strict框架和 Cookies
当使用任何涉及第三方 cookie 或第三方网站的操作时，iframe 就会出现问题。例如。如今，您无法从 iframe 执行 OAuth 登录，因为浏览器限制会丢弃所使用的 cookie。此外，出于安全原因，像 Google 这样的提供商将不允许他们的登录页面在第三方 iframe 中呈现。
总结
您可以通过分离上述前两种类型的请求来解决您的问题。为了最少的未来问题和最好的登录功能，尽可能避免使用 iframe。此外，设计将来可以将第一方 cookie 作为 API 凭据发送的基本 URL，例如：
https://www.mycompany.com/product1
https://www.mycompany.com/product2
https://www.mycompany.com/api