SPA和简单的后端与Oauth2相同的起源 - 使用http会话的方式

Question

使用简单的后端（例如Spring）和SPA前端以及OAuth2 auth提供程序，基于http会话实现授权的正确方法是什么？

术语“正确”是指模仿用户后端获取会话cookie的方法。

不幸的是，周围有“可伸缩，宁静，无国籍”的JWT炒作。但我的应用程序将被极少数用户使用，它只需要开箱即用的http会话提供的简单的旧安全性。 Okta解决方案的当前“提议”导致对API的每个请求进行验证，因此每次调用都会产生很大的开销，从而导致性能不稳定。

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

我在想的是这个场景的实现：

1. 用户访问SPA（Angular，React，等等）
2. SPA呼叫后端用户详细信息，403
3. SPA正在重定向到oauth提供商，例如。 1563
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提供商，例如。 1563
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