使用授权码授予而不使用cookie？

Question

我已经阅读了几个月的内容，似乎整个事情都可以集中在我下面总结的内容上。我正在努力达到最理想的状态：

• OAuth2
• OpenID 连接
• SPA/移动客户端
• 智威汤逊

上述组件具有银行级安全质量的解决方案。所以这似乎是有道理的。

• 使用授权代码授予而不使用服务器端会话和 cookie，因为此 OAuth 流比隐式流更安全。
• 不要创建服务器端会话或 cookie（此外也许还记得我的 cookie 来识别客户端之前是否已通过身份验证）。这更有利于扩展和整体简单性。
• 将 JWT / OpenID 连接令牌返回给客户端，以便客户端可以使用它来发出 API 请求并在客户端内做出授权决策。（我认为这就是 OAuth2 混合授权代码授予/隐式流程是什么？）。将 JWT / OpenID 连接令牌存储在客户端会话存储中。
• 拥有短暂的 JWT 令牌，并提供刷新令牌，直到用户注销。客户端将自动接收刷新令牌，除非超时/客户端会话过期或用户注销。刷新令牌将由 SPA/移动应用程序正在与之通信的边缘服务器/OAuth 客户端获取并提供服务。
• 注销（或超时）时，从浏览器会话存储中删除令牌。

这是否疯狂/听起来合理吗？它会跳过使令牌失效，但如果令牌的生命周期很短并且客户端可以获得刷新令牌，那么这样做似乎可以。我想使用 Spring-Boot / Spring Security 和 Angular 4/5 来实现这一点，我想知道我是否错过了任何明显的东西，或者也许有一种更简单的方法不会牺牲/降低安全性？

您还认为这会通过“银行”级安全标准检查吗？

Answer 1

更新：不再推荐隐式流。即使对于 SPA，建议使用带有 PKCE 的授权代码流

原答案

需要澄清的事情很少，

1.您必须对基于浏览器的应用程序使用隐式流

这是因为此类应用程序无法保密，也无法保护其收到的刷新令牌。OAuth2.0 RFC也解释了流程。

另外，根据 OAuth2.0刷新令牌定义，刷新令牌是一种凭证。

刷新令牌是用于获取访问令牌的凭据

RFC6749 的第 10.4节解释了有关刷新令牌安全性的更多信息，从而解释了基于浏览器的应用程序使用隐式流的需要。

2.隐式流不发送刷新令牌

来自OAuth2.0 RFC

使用隐式授权类型流程时，不会返回刷新令牌，这需要在访问令牌过期后重复授权过程。

因此，当访问令牌过期时，您必须通过相同的流程来获取新的令牌集

3. ID 令牌的使用

必须按规范进行检验。如果 id 令牌有效，则用户已通过身份验证

4.API调用

有两个选项，使用访问令牌或用户 ID 令牌。

使用访问令牌与 API 端点进行通信是很常见的。这是访问令牌的预期用途。从 API 端点，可以使用内省端点（如果身份提供者支持）来验证访问令牌。

但 ID 令牌 JWT 也可以用作不记名令牌。为此，API 端点将需要一个 warapper 来验证 ID 令牌。该博客/文档包含一些值得考虑的要点。