Angular 在不使用cookie的情况下使用授权码授权？

几个月来我一直在阅读这篇文章，似乎整个事情都可以集中在我下面总结的内容上。我正在努力达到最理想的境界：

• OAuth2
• OpenID连接
• SPA/移动客户端
• JWT

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

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

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

---

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

更新：不再建议使用隐式流。即使对于SPA，也建议在PKCE中使用授权代码流

---

原始答案

没有什么需要澄清的

1。您必须使用基于浏览器的应用程序

这是因为此类应用程序不能保密，也不能保护其接收的刷新令牌。也请解释一下流程

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

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

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

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

来自OAuth2.0 RFC

使用隐式授权类型流时，不支持刷新令牌 返回，需要重复一次授权过程 访问令牌过期

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

3。ID令牌使用情况

必须根据法律进行仲裁。如果id令牌有效，则对用户进行身份验证

4。API调用

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

使用访问令牌与API端点通信是常见的。这是访问令牌的预期用途。从API端点，可以使用（如果身份提供程序支持的话）虚拟化访问令牌

---

但是ID令牌JWT也可以用作承载令牌。为此，API端点将需要一个warapper来验证ID令牌。Blog／文档包含一些值得考虑的优点。

第一次阅读：但我想使用：OpenID连接一个经过验证的库：遵循OpenID连接的最佳实践，我知道你的意思是“如何问”提示-我觉得我是“走出盒子”一点以上的方法，所以，只要看看有没有人看到什么疯狂的东西，也许我应该考虑…wrt。1：从技术上讲，您也可以使用授权码授权，但只能对公共客户使用，因此没有客户。谢谢-回答得很好-这说明了我问这个问题的原因之一。我希望使用授权代码授权流，但使用刷新令牌，不使用会话（没有其他会话令牌/cookie），同时还将jwt令牌或刷新令牌返回给客户端/SPA进行资源服务器身份验证。这种类型的场景超出了OAuth2的标准/蓝图，但我认为可以通过稍微调整授权服务器来实现。我理解你的意思，尽管这需要（我认为）服务器端会话，这是我试图避免的。我希望没有服务器端会话的授权授予流的安全优势。IIUC在授权授予流完成后，边缘服务器/客户端应用程序（而不是浏览器）会正常创建会话标识符（Java中的JSESSIONID）。如果用JWT/OpenID连接令牌替换该标识符并将其发送到客户端，那么我们将受益于增强的授权授予流安全性，并根据需要刷新令牌。边缘服务器将对此进行管理。因此，当令牌到达边缘服务器时，边缘服务器可以验证签名并将其转发到资源服务器，或者如果令牌已到达过期窗口，则可以将其发送到授权服务器并请求刷新令牌。