解释 Open ID 连接中的离线令牌验证与在线令牌验证？优势、局限和权衡答案

【问题标题】：Explain Offline Token validation vs Online Token validation in Open ID connect ? Advantages, limitations & tradeoffs解释 Open ID 连接中的离线令牌验证与在线令牌验证？优势、局限和权衡
【发布时间】：2020-04-29 23:28:21
【问题描述】：

在为现有应用程序和后端服务开发 Open ID 连接模型的过程中，我很困惑选择是离线还是在线 JSON 令牌验证 ID 令牌和访问令牌。

我的开放 ID 提供者：KeyCloak

我的问题是关于令牌验证的想法，所以我不讨论实现细节。

根据 OIDC（开放 ID 连接），

ID 令牌将颁发给正在请求资源的服务一旦通过身份验证

现在在资源服务器端真的有必要使用 Open ID Provider 验证令牌（Keycloak）或离线验证令牌基于公钥。

如果我选择离线令牌验证模型 - 我必须面对的潜在影响/限制是什么。

我正在寻找理想的情况来选择合适的模型和所讨论的权衡取舍。

【问题讨论】：

标签： oauth-2.0 jwt access-token openid-connect keycloak

【解决方案1】：

在线验证的唯一优势是用户权限同时被撤销的可能性。通过离线验证，您可以证明令牌是由您的 Keycloak 颁发的并且没有人篡改它。每个请求的在线验证都太多了。

例如，在前端单击可能会导致许多 api 调用，并且在同一秒内向 Keycloak 创建十几个休息请求没有任何好处。建议缩短令牌的生命周期。

您可以在短时间内实现令牌缓存和在线验证令牌，但如果您可以在 Keycloak 中缩短令牌生命周期，那又有什么意义呢。

因此，总而言之，在超时持续时间（例如 5 分钟 - 应可根据用例配置）和超过该时间段发出新令牌时验证令牌脱机。

【讨论】：

这部分回答了我的问题。因此，您建议同时进行离线和在线验证 - 缩短访问令牌的生命周期将使获取新令牌。即不是验证现有令牌，而是始终使用新令牌。我想这仍然会被算作一个额外的电话。如果令牌在开放 ID 提供者处被撤销，那么在访问令牌生命周期之前，用户将继续访问其新令牌或现有令牌验证。
没有。我建议在短时间内使用新令牌，例如。 15分钟。我建议只对 api 调用进行离线验证。大多数框架都会为您做到这一点。我使用 .net 核心，并在初始化阶段框架类从众所周知的配置中加载公钥和其他数据。对于每个 api 请求令牌都经过验证，但仅离线。当您离线验证令牌时，您会检查令牌签名，因此您可以确定没有人更改令牌。您还需要检查算法和受众。
确实，如果您不在线检查令牌，则可能在最后 5 分钟内撤销了用户角色，但是对于您的用例来说，这个问题有多大？当有人离职时，我们会撤销用户权限，这几分钟不是什么大问题。另外，前端一键可以产生很多api调用，一秒钟内去Keycloak十次检查同一个token是没有意义的。
我同意，我已将编辑作为此答案的结论。

【解决方案2】：

在资源服务器端是否真的需要使用 Open ID Provider (Keycloak) 验证令牌

是的，您必须验证 OpenID Connect(OIDC) 协议定义的 ID 令牌。令牌验证有很多步骤，但主要涉及签名验证、颁发者验证。完成此操作后，您可以说 ID 令牌有效，从而标记最终用户进行身份验证。这是 OpenID Connect 的核心主体。

关于离线，公钥验证就足够了。例如，这意味着当您的授权服务器更改密钥链时（这种情况很少见，并且在存在安全漏洞时完成），您必须以某种方式再次更新您的密钥。

此外，还有 JWT 加密 (RFC7516)，它为令牌验证增加了一层额外的安全性（如果您担心安全性）。但如果我是正确的，KeyCloak 不支持这个。

在线验证的优势

您总是依赖授权服务器来验证令牌的有效性。

在线验证的缺点

您为授权服务器创建了更多流量。此外，您的应用服务器还需要一个 API 调用。

不管你总是需要授权服务器的公钥。

【讨论】：

【解决方案3】：

令牌验证是一方面，但它不是一个完整的安全解决方案。您经常会发现您需要来自令牌和其他来源的数据才能正确授权对资源的访问。

因此，您的解决方案取决于您想要授权的方式以及可用性和性能等非功能性要求。

由于关注点分离，我的个人偏好处于离线状态 - 请参阅我的 write up 了解更多详细信息。

【讨论】：