在不使用cookies的情况下使用授权码授予？

Posted 2023-03-10

【中文标题】在不使用cookies的情况下使用授权码授予？

【英文标题】：Using the authorization code grant without using cookies?

【发布时间】：2018-03-18 18:19:24

【问题描述】：

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

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

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

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

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

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

【问题讨论】：

初读：***.com/help/how-to-ask 但我猜使用：OpenID Connect 与认证库：openid.net/certification 遵循 OpenID Connect 的最佳实践openid.net/specs/openid-connect-basic-1_0.htmlopenid.net/specs/openid-connect-implicit-1_0.html

是的，我知道您所说的“如何提问”提示是什么意思 - 我觉得我在使用上述方法时有点“跳出框框”，所以只需检查是否有人看到任何疯狂的事情，也许我应该考虑......

【参考方案1】：

更新：不再推荐使用隐式流。即使对于 SPA，也建议将授权代码流与 PKCE 一起使用

---

原答案

有几件事需要清理，

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

这是因为此类应用程序不能保密，也不能保护它收到的刷新令牌。 OAuth2.0 RFC也解释一下流程。

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

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

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

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

来自 OAuth2.0 RFC

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

所以当访问令牌过期时，你必须通过相同的流程来获取新的令牌集

3. ID 令牌使用情况

必须根据specficiation 填写。如果 id 令牌有效，则用户通过身份验证

4. API 调用

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

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

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

【讨论】：

写。 1.：从技术上讲，您也可以使用授权码授权，但只能使用公共客户端，所以没有 client_secret

谢谢 - 很好的回答 - 它说明了我提出这个问题的原因之一。我想使用授权代码授权流程，但使用刷新令牌，没有会话（没有其他会话令牌/cookie），同时还将 jwt 令牌或刷新令牌返回到客户端/SPA 以进行资源服务器身份验证。这种类型的场景超出了 OAuth2 的标准/蓝图，但我认为可以通过稍微调整授权服务器来实现。

我明白你的意思，尽管这需要（我认为）服务器端会话，这是我试图避免的。我想要授权授予流程的安全优势，无需服务器端会话。

IIUC 在授权授予流程完成后，边缘服务器/客户端应用程序（不是浏览器）正常创建会话标识符（Java 中的 JSESSIONID）。如果将该标识符替换为 JWT / OpenID 连接令牌并将其发送到客户端，那么我们将受益于增加的授权授予流安全性并根据需要刷新令牌。边缘服务器会管理这个。

所以当令牌到达边缘服务器时，边缘服务器可以验证签名并将其转发给资源服务器，或者如果令牌已经到达过期窗口，它可以将其发送给授权服务器并要求刷新令牌。