用于基于REST的应用程序的JWT身份验证的企业模式？

JWT规范仅描述了有效负载及其发送方式，但未启用身份验证协议，从而允许了灵活性，但非常不幸的是，灵活性可能导致反模式和设计错误。

我正在寻找一些经过深思熟虑且经过测试的JWT身份验证企业模式，可以使用或改编它，但未能找到完整的东西。

我在想的是：

• 当未满足任何授权标头或JWT令牌无效或已过期时，发送HTTP 401
• 为了进行身份验证，请使用/ login REST通道，将用户名和密码作为JSON对象发送
• 为了使令牌保持活动状态，请使用/ keepalive REST通道，每N（5）分钟调用一次，接收新的JWT令牌，并在每次调用后替换现有的令牌（令牌在M（15）分钟后过期）

但是，令我困扰的是该/ keepalive频道的必要性。另一方面，它迫使我防止身份验证过期，即使用户不在（该决定，如果我们希望仍然不执行keepalive的决定），当然，这是对协议的额外调用和额外复杂性。有趣的是，服务器会自动延长令牌。在基于会话的环境中，它是通过重置时间戳来实现的，但是，在这里，服务器将不得不发送新令牌，可能不是每次都发送一次，但是一旦令牌在R（例如10）分钟内到期，就必须发送新令牌。但是将其放在响应主体中将意味着修改JSON响应协议（因此，该解决方案具有侵入性且不透明），并且将客户端可以处理的额外HTTP标头不一定不一定是一个好模式。一世'

有没有可以解决我的问题的现成企业模式？我的协议草案是否可靠？与从头开始设计相比，我更喜欢使用现成的东西。

JWT（JSON Web令牌简介）只是一种令牌格式，身份验证完全超出了该规范的范围。实际上，它确实是身份验证系统中常用的，但是您也可以将其用于完全不同的场景，因此在该规范中不包括特定于身份验证的约束是有意义的。

如果您正在寻找有关认证的指南，则应参考OpenID Connect系列规范。此外，如果您的系统由HTTP API组成，并且您有兴趣向自己或第三方客户端应用程序提供对这些API的委派访问权限，则应参考OAuth 2.0规范。

还有其他与身份验证相关的协议，例如SAML和WS-Federation，它们仍在企业场景中广泛使用，但是实现起来却要复杂得多。

关于您的特定开放点：

• 承载令牌认证方案在RFC 6750中定义，其中包含有关如何执行请求的说明以及可能的错误代码。
• OAuth2和OpenID Connect都在考虑这种可能性，并定义了使用令牌交换用户名/密码的方式。
• 通过刷新令牌在OpenID Connect和OAuth2中解决了延长自包含/按值令牌（JWT）生存期的问题。

尽管OAuth2和OpenID Connect可以比其某些前辈更易于实现，但它们仍然足够复杂，需要谨慎行事，只有在您愿意花费大量时间和资源的情况下才能自己实现。通常，使用第三方库或服务为您完成繁重的工作是更好的选择。

最后，这些协议涵盖了很多情况，因此在某些情况下可能会显得过大。

我认为您不需要保持活动频道。当登录时生成令牌时，您的有效载荷可以（并建议）包含服务器提供的到期信息（在exp密钥中，根据标准）。如果使用了过期的令牌（很明显，这是由服务器确定的，并且只有在签名验证后才信任令牌中的内容），服务器会简单地使用HTTP 401拒绝令牌，提示客户端重新进行身份验证。

同时，客户可以积极主动。有效负载部分未加密，并且由于客户端可以读取它，因此客户端可以确定何时发送带有过期令牌的请求，因此/login如果令牌过期则再次调用。

另外，REST允许将超媒体信息作为“状态引擎”发送，因此，如果您愿意，您实际上可以将JWT一次性使用，并且也将到期。然后，每个请求都将生成一个新的JWT，该新的JWT在响应中返回给客户端，就像在hapi-auth-jwt2中那样，在内容中或更可能在响应标头中返回。