JWT 电子邮件验证协议

Question

我对 Web 应用程序上的帐户创建过程中的电子邮件验证步骤有一个想法。这是我第一次构建这样的东西，所以我只是想确保这个协议是安全的。

由于我真的不想在我的数据库中为“未验证”用户存储任何内容，因此我想到了使用 JWT 来验证用户的电子邮件地址。这是我的想法：

1. 用户访问网站上的/register端点并输入他的电子邮件（只有他的电子邮件，暂时没有用户名和密码）。
2. 我在后端服务器上使用正则表达式验证电子邮件格式，并检查与域名关联的 MX DNS 记录。
3. 我创建了一个 JWT，其中包含他作为唯一数据提供的用户电子邮件地址。之后，我向该地址发送一封电子邮件，其中包含指向新端点的链接：/create?token=<generated jwt>。 （此令牌经过加密签名，可防止生成已绑定到电子邮件地址的注册链接）。
4. 如果这封电子邮件属于用户，他只需点击链接，我现在就知道该地址有效。
5. 用户可以在这个新的/create 端点上完成他的注册，他将被要求提供用户名和密码。

我认为这种方法会更加用户友好，因为用户不必输入他的用户名和密码两次（1：注册，2：点击电子邮件链接后登录）并且对我的数据库更有效我根本不跟踪未经验证的用户。
最重要的是，在 JWT 上设置的过期时间非常方便，因为我可以将其设置为 24 小时（创建后），链接会立即变得不可用。

我只需要在/create 端点上显示电子邮件地址，以确保有人没有将绑定到他的电子邮件地址的链接发送给其他人进行注册（这将使此人能够重置受害者的密码之后）。这很容易通过在用户名和密码提示旁边显示一个包含电子邮件地址的不可编辑字段来防止。

Answer 1

您可能应该使用（并检查）jwt 中的iss 和aud 字段来指示您的哪个网站为哪个（可能是它自己）颁发了令牌。虽然您只在一个网站上使用它，但这并不重要，但对于多个网站，它会变得更加复杂，最好在消息中包含谁将它发送给谁。

考虑到适合 url 的最大长度，jwt base64 编码（我猜）可能会变长（但我认为上述情况可行，所以有了这些数据，我认为它已经不会太长了） .

这也允许对 jwt 秘密进行已知明文攻击，因为您将发布一个新的 jwt 并将其发送到任何电子邮件地址。可能您可以对/register 端点设置某种速率限制来缓解这种情况。这也可能有拒绝服务方面的问题，因为签署 jwts 和发送电子邮件可能会占用大量资源。

最后，您在上一段中提到的威胁（用户将自己的链接发送给其他人，以便他们使用攻击者的电子邮件地址进行注册）是一个很好的威胁。仅显示电子邮件地址可能不足以缓解，这完全取决于您的场景，甚至我猜用户如何显示或确认它的视觉效果。这当然是攻击您的用户的一种方式，一种更强的缓解措施是如果他们需要再次输入他们的电子邮件地址并将其与 jwt 中的地址进行比较 - 但这是为了换取更糟糕的用户体验，权衡是由您决定.例如，如果您认为这对您的应用程序来说已经足够了，您也可以明确地让用户确认电子邮件地址，这很好。