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

Question

我已经阅读了好几个月，似乎整个事情可能会在我下面总结的内容上有所收敛。我想在最理想的到来：

• 的OAuth2
• ID连接
• SPA /移动客户端
• JWT有银行级别的安全质量为上述

解决方案组件而言。所以这似乎是有道理的。

• 使用Authorization Code Grant而不使用服务器端会话和cookie，因为此OAuth流比隐式流更安全。
• 不要创建服务器端会话或cookie（除了可能记住我的cookie来识别客户端之前是否已经过身份验证）。这对缩放和整体简单性更好。
• 将JWT/OpenID连接令牌返回给客户端，以便客户端可以使用它来发出API请求并在客户端内作出授权决定。 （我认为这是OAuth2混合授权代码授权/隐式流程是什么？）。将JWT/OpenID连接令牌存储在客户端会话存储中。
• 拥有短暂的JWT令牌，并在用户注销之前提供刷新令牌。客户端会自动接收刷新令牌，除非它超时/客户端会话过期或用户注销。刷新令牌将由SPA /移动应用正在与之交谈的/ OAuth客户端的边缘服务器获取并提供服务。
• 在注销（或超时）时，从浏览器会话存储中删除令牌。

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

你是否也认为这会通过“银行”级别的安全标准检查？

Answer 1

几件事情要清除掉，

1.你必须使用implicit flow的基于浏览器的应用程序

这是监守这样的应用程序无法进行保密，不能保护它临危刷新令牌。 OAuth2.0 RFC也解释了流量。

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

刷新令牌来获得访问令牌

部分10.4 of RFC6749介绍了更多关于刷新令牌的安全性，从而解释了需要使用基于broweser应用隐流凭据。

2.隐流不发送令牌

刷新从RFC的OAuth2.0

当使用隐式交付式流动，刷新令牌不是 返回，这需要重复授权过程一次 访问令牌到期。当访问令牌到期

所以，你必须去通过相同的流走新型标记设置

3 ID令牌使用

必须根据specficiation vlaidate。如果ID令牌是有效的，用户进行身份验证

4. API调用

两个选择，要么使用访问令牌或用户ID令牌。

访问令牌与API端点通信的用法很常见。这是访问令牌的预期用法。从API端点，访问令牌可以使用introspection endpoint（如果身份提供商支持一个）进行vlaidated。

但是，ID令牌JWT也可以用作不记名令牌。为此，API端点将需要包装器来验证ID令牌。 This博客/文档包含一些要考虑的优点。