Jwt-auth: 更新令牌流用户体验

感谢您花时间写出所有这些。 如果你觉得接下来的任何事情都很苛刻，这不是故意的，我只是给你我的意见，而不是唯一的意见，它们可能是混合的，辩论很好。

我担心此更改会使大多数非技术用户无法访问此插件的功能，他们希望能够使用他们的用户名和密码登录。

我明白你想在这里说的话，但同时你的建议是要求用户登录 WordPress 并创建密钥对对于想要生成令牌的非技术用户来说有点困难以编程方式通过 REST API。 我认为这些根本不是 _non-technical_ 用户。

同样，在每个安全系统中，用户必须克服进入障碍才能使用它。 Google 不允许您在 API 请求中使用您的用户名和密码来创建 JWT 或 OAuth 连接。 那不安全。 必须有一种方法来确保令牌或身份验证连接以一种可以无效的方式附加到用户。

这不直观
任何其他想要使用此方法与 WordPress 集成的系统都需要有关于如何设置密钥对的说明/教程才能开始使用。

为了拥有一个支持访问和身份验证分离的安全模型，您必须拥有防止长期令牌成为无限访问点的护栏。 通过添加刷新令牌，恶意用户可以使用user:pass组合创建访问和刷新令牌，如果没有密钥对或其他等效物来使令牌无效，我们永远不会使令牌无效。

告诉用户登录 WordPress 并转到他们的个人资料以生成密钥对是为了安全而付出的小代价。 同样，方向也很简单。

很难在设备之间使用
如果我希望将此密钥用于我手机上的应用程序，则没有简单的方法可以实现。 我不想在手机上输入一长串字母、数字和特殊字符——我很可能会出现转录错误。 我们可以通过生成人们可以扫描的二维码来消除转录难度级别，但随后我们又回到了上面的问题——人们可能需要下载一个二维码应用程序，或者第三方开发者需要构建一个二维码将库解析到他们的应用程序中以便与我们合作。

请描述您一直提到的这个应用程序，为什么它会为您处理所有身份验证和登录？ 那不安全。 您将为该应用程序提供所需的所有访问权限和身份验证，以便对您的网站执行任何操作。 您应该考虑可能应用程序架构不正确，并且此身份验证流程是为了防止您描述的确切内容。

您向我描述的是一个应用程序，它存储您的纯文本用户名和密码，因此它可以通过 REST API 登录到 WordPress 以生成用于访问资源的令牌，但也完全能够通过相同的方式转储您的数据库身份验证和访问的方式。 我不明白为什么我们要支持任何与您描述的这个用例接近的远程项目。

它不鼓励良好的安全卫生
理想情况下，用户会小心地维护他们的密钥，以确保没有过期、未受损害等。不幸的是，我们不能指望这一点，被泄露的密钥比被泄露的令牌更危险。 普通用户也有可能在每次需要时创建一个新密钥，而不是将秘密存储在安全的地方。

首先，密钥对没有附加到到期日期，他们现在唯一能做的就是创建令牌，所以我看不出它们比受损令牌更危险，因为它们是使令牌无效的东西。 其次，用户什么都不做，我们永远不应该期望他们理解他们的行为的安全含义。 我们必须假设他们非常无能，而且很可能懒惰到永远不会自己清理。 但是，创建额外的密钥对不是安全问题。 安全问题是将您的纯文本用户名和密码提供给外国应用程序。

另外——我担心添加一个额外的方法来撤销会话——WordPress在个人资料页面上已经有一个“在其他地方退出”按钮——作为用户，我希望这也会让我退出任何应用程序（或者至少提示我是否愿意这样做？）

我们可以提示用户删除他们的密钥对，但我永远不会期望注销会破坏我的令牌。 这不是此类系统的正常或预期行为，可能会造成混乱和大量支持请求。

它不提供任何额外的安全性
如果我作为攻击者已经拥有您的用户名和密码，那么我就没有什么不能像您一样做的（假设没有 2FA）。

我断然不同意。 这种方法为访问您的 REST 资源提供了额外的安全性，如果这不明显，那么我们需要更多的文档来使其显而易见。 您认为如果有人已经拥有您的凭据，那么您就完蛋了，但您还建议我们使用它们来授予对 REST API 的访问权限。 如果这是您想要访问 REST 的方式，请使用基本身份验证。 因为如果我们使用user:pass来创建令牌，这正是我们将要实现的。

这导致这样一个事实，如果我作为一个新手应用程序开发人员想要让我的用户的生活更轻松，我可能会尝试一些不明智的事情，例如使用无头浏览器登录用户的帐户，创建令牌，阅读详细信息，然后将它们拉回我的应用程序。

这是我们想要创建一个身份验证流程的地方，它允许通过使用回调为应用程序提供密钥对。 我相信这样的事情已经在应用程序密码插件中实现了。

我 100% 愿意为应用程序创建一个身份验证流程，当您访问它时，您会被要求登录 WordPress，并添加 2factor 之类的任何附加功能，这将为您生成一个密钥对，然后使用某种回调给应用程序密钥对。 然后应用程序开发人员不必创建大量糟糕的解决方案，应用程序也不会存储他们的user:pass 。

可以做些什么呢？
密钥目前有一个重要目的——它用于允许撤销令牌，尽管令牌可能非常长。 但是，我们不一定需要密钥对来执行此操作。

正确，您可以使用许多不同的方法。

从 WordPress 的 usermeta 中的 session_tokens 条目中汲取灵感——一组存储的 JWT 特定的撤销密钥将允许相同的功能，并且它会使实现“在其他地方注销”功能变得微不足道——只需从表中删除该条目即可。

这永远不会替代它必须添加的当前实现。 作为企业软件开发人员，我永远不会使用这种方法。 因此，即使它是一种有效的方法，它也无法期望令牌只要它没有过期或令牌没有被撤销就有效。 在您的场景中，您第二次注销令牌无效。 这将是 IMO 身份验证流程中的一个缺陷，它会导致我的应用程序获得资源访问权限的无数问题，因为它现在与正在登录的用户紧密耦合。

2FA呢？
我想知道是否有可能允许 2FA 插件可以用来告诉客户端“请再试一次，提供 2FA 令牌”的钩子（如果需要，但未提供）。 此外，可以使用另一个钩子（或者可能是相同的钩子？）来允许 2FA 插件验证提供的代码是否正确？ JWT 系统不会对 2FA 的实现方式做任何假设——这将留给另一个插件——我们只是提供钩子来使这样的事情成为可能。

这将 IMO 增加不必要的复杂层，有可能创建大量支持请求。

感谢您阅读到这里 - 以上所有内容都是恕我直言，但我希望我们可以为用户简化这个过程，使其对每个人都开箱即用。

我确定我至少错过了一些东西，所以我很高兴听到人们对此的任何反馈！

史诗般的帖子。 感谢您花时间写下所有这些。 你确实考虑了很多。 我想说我不是要击落任何东西。 只是，如果我们要允许使用user:pass组合创建令牌，那么我们这样做的方式需要非常安全，并且应用程序存储您的登录凭据的可能性为零。

将访问和身份验证分开是有目的的，不应掉以轻心。 我们正在为 1/3 的互联网构建潜在的 REST 身份验证。 因此，在我们找到前进的道路之前，我删除了使用用户凭据创建令牌的功能。 这并不意味着我们不能将其添加回来，只是在我们这样做之前需要进行大量讨论。

你好！ 据我了解，这里对话的主要痛点是可用性。 对于某些用户来说，确实让用户去站点登录并创建密钥对将是问题或不便的根源。

开发人员可能会尝试找到不安全的方法来避免这种情况，就像今天他们为了用户而删除需要强密码的功能一样。

虽然我确实理解决定中的安全方面，并且有点同意。 但是我们需要找到一种对两者都有效的方法。

看来你在这里@valendesigns 所说的可能是一个可能的解决方案：

我 100% 愿意为应用程序创建一个身份验证流程，当您访问它时，您会被要求登录 WordPress，并添加 2factor 之类的任何附加功能，这将为您生成一个密钥对，然后使用某种回调给应用程序密钥对。 然后应用程序开发人员不必创建大量糟糕的解决方案，应用程序也不会存储他们的用户：通行证。

据我了解，基本上我们会保持当前的流程，这更安全，因为我们不需要将密码提供给应用程序，而是只提供密钥对来生成令牌，但这对某些人来说可能是一个障碍.

保持其他流程，我们不需要将密码提供给外部应用程序。 相反，要求他们登录 WordPress 并生成密钥对。

我确实想了解有关这部分的更多信息：

我们可以提示用户删除他们的密钥对，但我永远不会期望注销会破坏我的令牌。 这不是此类系统的正常或预期行为，可能会造成混乱和大量支持请求。

如果我通过浏览器和应用程序登录 site.com，如果我在浏览器中单击“在其他地方退出”，我也会在应用程序中退出，不是吗？！ 我可以看到这是假设的应用程序。 期望您会在任何地方注销。

删除帐户时也需要发生同样的情况。

我必须同意关于密钥对 UX 对用户非常不友好的说法。

构建可以使用此身份验证方法的本机移动应用程序变得非常困难。

• 不久前，我为（旧的）OAuth1a 插件制作了一个自定义插件，该插件在应用程序管理页面（当应用程序名称和回调 url 与我的应用程序匹配时）显示了一个加密的（带有一个简短的、可设置的密码）二维码，然后将客户端应用程序信息传递给移动应用程序，然后允许用户进行身份验证。

诚然（双关语），JWT 比 OAuth1a 容易得多；）

由于用户首先必须使用用户名和密码登录 Wordpress（希望通过 https），我真的不明白让用户名/密码对能够获得访问令牌的安全问题是什么? 这一切都是在一天结束时通过同一条“线路”发送的？ 一定？

强制执行当前实现的应用程序密钥对使得这种身份验证方法（在现实世界中）绝对不可能用于移动应用程序。

没有明智的方法让移动应用程序输入它们。

我已经尝试了 OAuth1a、OAuth2 和现在的两个 JWT 插件来实现我的具有访问权限的本机应用程序，但所有这些都失败了“开箱即用”，没有一些黑客尝试让事情为用户工作。 这个东西应该会变得更容易，是吗？

第三方JWT 插件（安装次数超过 10,000 次）支持 user/pass，并且适用于我一直在构建的本机移动应用程序。 但是由于插件缺少刷新令牌而失败，迫使用户再次“登录”。 （它还需要手动编辑 wp-config）

这个“即将成为官方的”（我希望！）插件由于缺乏移动用户友好性而失败，并且似乎忽略了实际可以为其开发什么样的应用程序。 这似乎很短视。

缺少用于发布到 wp.org 网站的本机移动应用程序是有原因的。 就是这个。

拜托，拜托，我们能对此有所动议吗？ （自从引入 REST API 以来，我多年来一直在开发本机应用程序，等待一种“正确”的方式来验证用户身份）

:)

令牌流 UX 是疯狂的，对于现实世界的使用来说是不切实际的，用户应该能够在系统上使用用户名和密码登录，要求提供 API 密钥对没有任何意义，你在这里没有使用抽象，你应该为了保护用户免受使用您的应用程序的技术细节的影响，为了在您的手机上登录 Facebook，您需要登录 Facebook 上的管理门户并创建 API 密钥对，然后使用 API 密钥对，您会有什么感觉？登录，我们不是为开发人员开发，我们是为那些不知道您的服务的技术方面包括什么的客户开发，立即卸载。 我真的不明白这个插件如何用于身份验证。

用户登录 > 令牌流的这个问题严重阻碍了许多可能使用 JWT 的应用程序的开发。

几个月又几个月过去了，它根本没有得到解决。

正如我上面所说，用户使用用户名/密码对实际登录到管理员这一事实使得不使用用户名/密码对来获取令牌的任何论据似乎有些无效？ 一定？

只是为了更新这个线程——听起来这个项目正在被一个在 WP 核心中实现完整的 OAuth 流程所取代。 它应该解决这里讨论的方法的缺点，同时保留所有优点。

如果您想参与其中，请随时跳入Slack 上的 #core-restapi 。