与Oauth2在同一源上的SPA和简单后端 - 使用http会话的方式

Question

使用简单的后端(例如 Spring)和 SPA 前端和 OAuth2 身份验证提供程序，基于 http 会话实现授权的正确方法是什么？

术语"正确"是指一种将用户模拟到后端以获取会话cookie的方法。

不幸的是，到处都是"可叫的、宁静的、无状态的"JWT 炒作。但是我的应用程序将被很少的用户使用，它只需要由 http 会话提供的开箱即用的普通旧式良好安全性。Okta解决方案当前"提出"的方法是验证对API的每个请求，因此每个调用都有显着的开销，从而导致性能不佳。

假设我们在 myapp.com 上公开了 SPA 应用程序，并且其后端通过 myapp.com/api 在代理上公开。

我正在考虑的是此场景的实现：

1. 用户访问SPA(Angular，React等)
2. SPA 调用后端以获取用户详细信息，403
3. SPA 正在重定向到身份验证提供程序，例如。奥克塔
4. 用户登录到 OAuth 提供程序
5. OAuth 提供程序授予持有者令牌并重定向回 SPA
6. SPA 调用后端以获取用户详细信息，但现在带有持有者
7. Spring 接收 OAuth2 授予的令牌，在 OAuth 提供程序中验证这一点，创建 HTTP 会话并授予会话 cookie (JSESSIONID)
8. 对后端的SPA调用会自动填充cookie(我们正在与代理通信，因此它是同一个域)

或者也许：

1. 用户访问SPA(Angular，React等)
2. SPA 调用后端以获取用户详细信息 403，因此后端重定向到 oauth 提供程序，例如。奥克塔
3. 用户登录到 OAuth 提供程序
4. OAuth 使用 OAuth2 令牌重定向回后端
5. Spring 接收 OAuth2 授予的令牌，在 OAuth 提供程序中验证这一点，创建 HTTP 会话并授予会话 cookie (JSESSIONID)，并重定向到 SPA
6. SPA调用后端以获取用户详细信息(自动填充cookie)，200

是否有开箱即用的可用配置？看起来这两种情况都需要在弹簧安全方面进行大量工作和配置。可悲的是，很难找到与 http 会话 cookie 与 SPA 和 oauth2 提供程序相结合的任何资源。

或者也许我错过了什么？

Answer 1

JHipster实现了(更安全的)第二种方案(也称为授权代码流)。它的实现基于Spring Security的OAuth支持。

我们已经用Keycloak和Okta测试了所有内容，但它应该适用于任何符合OIDC标准的IdP。

http://www.jhipster.tech