JWT电子邮件验证协议
我对在web应用程序上创建帐户过程中的电子邮件验证步骤有一个想法。这是我第一次构建这样的东西，所以我只想确保这个协议是安全的。
由于我真的不想为‘非验证’用户在我的数据库中存储任何东西，所以我想使用JWT来验证用户的电子邮件地址。这是我的主意：
- 用户访问网站上的
/register端点并输入他的电子邮件(暂时只输入他的电子邮件，没有用户名或密码)。 - 使用后端服务器上的regex验证电子邮件格式，并检查与域名相关的MX DNS记录。
- 创建了一个包含用户电子邮件地址的JWT，他提供的电子邮件地址仅作为数据提供。之后，我向该地址发送一封电子邮件，其中包含指向一个新端点的链接：
/create?token=<generated jwt>。(此标记是加密签名的，防止生成已绑定到电子邮件地址的注册链接)。 - 如果这封电子邮件属于用户，他只需单击该链接，我现在就知道该地址是有效的。
- 用户可以在这个新的
/create端点上完成注册，在那里他将被要求提供用户名和密码。
我认为这种方法对用户更友好，因为用户不必输入他的用户名和密码两次(1:注册，2:点击电子邮件链接后登录)，而且对我的数据库更有效，因为我根本不跟踪未经验证的用户。
最重要的是，在JWT上设置的过期时间将非常方便，因为我可以将其设置为24小时(在创建它之后)，并且链接将立即变得不可用。
我只需要在/create端点上显示电子邮件地址，以确保某人没有将绑定到其电子邮件地址的链接发送给其他人注册(这将使此人能够在稍后重置受害者的密码)。通过在用户名和密码提示旁边显示包含电子邮件地址的不可编辑字段，这是非常容易避免的。
Stack Overflow用户
发布于 2021-01-26 08:38:17
您可能应该使用(并检查) jwt中的iss和aud字段来指示您的哪个网站发布了哪个令牌(可能是它本身)。虽然你只在一个网站上使用这个，这并不重要，但对于多个网站，它变得更加复杂，这总是一个好主意，包括在信息谁发送给谁。
考虑到url中的最大长度，jwt 64编码(我猜)可能会变长(但我认为上面的场景可以工作，所以对于这些数据，我不认为它太长了)。
此外，这允许对jwt秘密进行已知的明文攻击，因为您将发布一个新的jwt并将其发送到任何电子邮件地址。也许您可以在/register端点上设置某种速率限制来缓解这种情况。这也可能有拒绝服务方面，因为签署jwts和发送电子邮件可能相当资源沉重。
最后，您在最后一段中提到的威胁(用户向其他人发送自己的链接，以便他们注册攻击者的电子邮件地址)是一个很好的威胁。只有显示电子邮件地址可能是不够的缓解，这完全取决于您的场景，甚至视觉效果将如何显示或承认的用户，我猜。这当然是攻击用户的一种方式，一个更强的缓解措施是，如果他们需要再次输入自己的电子邮件地址，然后将其与jwt中的地址进行比较--但这是为了换取更糟糕的ux，需要您做出决定。例如，您也可以显式地让用户确认电子邮件地址，如果您认为这足够您的应用程序，它可以很好。
https://stackoverflow.com/questions/65894184
复制相似问题
腾讯云开发者
