OpenID Connect 与无状态 JWT 令牌答案

【问题标题】：OpenID Connect with stateless JWT TokensOpenID Connect 与无状态 JWT 令牌
【发布时间】：2015-02-05 23:30:29
【问题描述】：

我想将自托管 OpenID Connect (OIDC) 服务器与 JWT 结合使用作为授权令牌（OIDC 术语中的访问令牌）。 JWT 将用于保护 REST 服务，而 UI 是经典应用程序和单页应用程序 (Angular) 的混合。这样，REST 层将能够基于无状态 JWT 令牌进行授权，因此不需要额外的数据库连接，如下所述：

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

对于单页应用，OIDC 隐式流是合适的。但是，当隐式流与无状态 JWT 令牌结合使用时，我发现了一个安全问题：令牌作为 URL 中的片段部分提供，这意味着无法删除它们（它们在浏览器历史记录中很容易获得）也不会失效它们（它们是无状态的）-> 无法注销。

我看到 2 个选项可以缓解这种情况：

使用非常短暂的令牌（最多几分钟）。这可能会严重影响可用性。
通过 AJAX 使用授权码流。这不符合 OIDC，但由于令牌不会在 URL 中公开，因此可以注销。

第三种选择是放弃无状态的 JWT 令牌并使用简单的不记名令牌和 DB 检查。

我错过了什么吗？你会选择什么？

【问题讨论】：

标签： security authentication single-sign-on jwt openid-connect

【解决方案1】：

人们可能会争论碎片最终出现在浏览器历史中的风险，但“简单”不透明的不透明承载令牌将受到您为 JWT 令牌描述的相同限制

OpenID Connect 规范当然不会阻止使用带有 AJAX 的代码流，因此您可以使用它；隐式流程只是对浏览器内客户端的建议，因为它优化了往返次数以获取用户代理的令牌

【讨论】：

简单的不透明承载令牌可能会被用户显式撤销，至少在理论上是这样。但在现实生活中，这不太可能。
同意，但我的观点是，它们最终以与 JWT 令牌相同的方式出现在浏览器历史记录中，有可能在它们被撤销之前被重新使用（想象一下关闭浏览器或甚至崩溃）