Quarkus OIDC 会话 cookie 限制

Question

在将我的应用程序升级到 quarkus 3 期间，我偶然发现了 https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.0#session-cookie-is-encrypted-by-default 中的 4kB cookie 限制以及下面的解决方案建议。

1. 分割 id / 访问令牌 / 刷新令牌的 cookie 没有任何效果
2. 我的应用程序确实需要令牌内部的角色，所以我无法切断它们
3. 使用数据库访问注册自定义 TokenStateManager 似乎需要付出很大的努力。
4. 不加密 cookie 的选项对我来说似乎是显而易见的解决方案，在 TLS 通信中，http 标头中的 cookie 无论如何都应该加密。但那为什么 quarkus 现在要引入这个功能呢？我是不是错过了什么重要的事情？

Answer 1

如果您可以发布一些 cookie 项目大小（加密的和未加密的）以更好地了解正在发生的情况，这将很有用。

加密

Auth cookie 应该加密，通常使用 AES256-GCM 等对称算法，加密字节编码为 Base 64。这应该会增加 30% 左右的大小，但不会大幅增加。然而，如果以 5 部分 JWE 格式发布加密的 JWT，则可能会解释巨大的大小差异。

不透明代币

如果支持的话，这是减少 cookie 大小的好方法，而无需在每个应用程序中维护自己的令牌存储。访问和刷新令牌都是像 UUID 这样的小值。

代币签名算法

有时您可以使用不同的算法来减小大小。例如，经常使用 RSA256，但它并不是最安全的，并且还会产生较大的 JWT 签名。出于兴趣，EdDSA 是一个非常安全的选项，可以生成小签名。

限制 Cookie 发送

除了分割令牌之外，看看是否可以像这样配置不同的 cookie 路径，以减少整个 cookie 标头的大小：

• 访问令牌路径：/
• 刷新令牌路径：/refresh
• ID 令牌路径：/claims

限制 cookie 发送也是一个很好的安全实践。例如，如果浏览器调用 API，则不需要刷新或 ID 令牌。

Cookie 限制

除非您有非常大的 JWT，其中单个 cookie 超过 4KB，否则我认为您在主要桌面和移动浏览器中应该没问题。发布有问题的特定浏览器的详细信息。

在最近的测试中，我发现移动和桌面浏览器的每个域的最大 Cookie 大小可能超过 4KB。某些 HTTP 服务器（例如 NGINX）的默认总限制为 4KB，但可能需要扩展。

总结

在我工作的 Curity，我们在称为

the token handler pattern

的 Web Cookie 解决方案中使用了上述一些成分，其目标是以最方便的方式使用 Cookie。