我们有一个Web应用程序，它生成了一个用于身份验证的内部JWT和一个安全Cookie沿着。由于该组织一直在迁移到Okta，因此要求将该登录流程集成到我们的应用程序中。
我们目前的工作流程：
- 我们有一个Sping Boot （版本2.5.x）登录端点，它接收userId和Password。
- 验证登录，然后创建一个内部jwt，其中包含userId、分配的角色和其他一些元数据。
- FE客户端接收该jwt并为每个经过身份验证的请求发送它。
它带来了很多挑战。经过一番分析，我想我明白了我想如何处理它：
- Okta应用程序被配置为“授权类型”。重定向和注销回调指向FE客户端URL
- FE客户端调用Okta服务器获取authorizationCode
- FE客户端调用BE服务器执行
/sso-login操作，传入authorizationCode作为参数 - BE调用okta
{okta-server}/token端点以获取okta承载令牌，并解析结果以获取userName - 内部JWT基于用户名和相关角色生成，并与安全cookie一起沿着发送回FE
这种流动有意义吗？安全吗？我看到的大多数文献和例子都倾向于涉及SPA或整合BE中的所有内容。
由于Spring oauth2集成的不透明性，我现在倾向于避免这种情况，并手动构造对/token端点的POST调用。
2条答案
按热度按时间bttbmeg01#
我不建议你创建自己的JWT。我建议将前端和后端打包在一起，并在后端进行所有身份验证。特别是如果您的应用程序位于同一主机上。如果它们不能存在于同一个主机上，请在前端进行身份验证，并将访问令牌传递给后端。
这两个教程展示了如何将应用程序打包在一起，同时保持单独处理它们的开发工作流。
本教程展示了如何在前端进行所有身份验证：
请让我知道这是否有帮助！
laawzig22#
根据最新的建议，OAuth2客户端（令牌被传递到的应用程序，以及存储这些令牌的应用程序）应该是“机密的”（用某种秘密来保护）。这需要它在你信任的服务器上运行（浏览器中基于JavaScript的应用程序和移动的应用程序都不能保密）。
这意味着，要遵循OAuth2最佳实践，您的React应用不应该是OAuth2客户端也不能访问令牌。它对后端的请求应该使用会话cookie进行授权（这需要防止CSRF攻击）。
我在this app（使用Angular）或this other one（使用React但使用法语README）中使用的模式是将
spring-cloud-gateway示例设置为负责请求路由和授权的BFF。当需要用户身份验证时：authorization_code流而退出使用此模式，请求受到以下内容的保护：
如果您使用浏览器调试工具（Gmail，Facebook，LinkedIn等）检查任何严重的OAuth2应用程序，您会发现会话cookie，但没有带有Bearer令牌的
Authorization头部。您甚至不会在浏览器中找到OAuth2令牌。原因是他们采用这种模式...