SPA和使用Oauth2源自同一来源的简单后端-使用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正在重定向到oauth提供商，例如。 Okta
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提供商。 Okta
3. 用户登录到oauth提供商
4. oauth使用oauth2令牌重定向回后端
5. spring接收oauth2授予​​的令牌，在oauth提供程序中对其进行验证，创建http会话并授予会话cookie（JSESSIONID），然后重定向到SPA
6. SPA调用后端以获取用户详细信息（自动填充cookie）200

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

或者我可能错过了什么？

Answer 1

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

我们已经使用Keycloak和Okta进行了所有测试，但它应可与任何符合OIDC的IdP一起使用。

http://www.jhipster.tech