在 ASP.NET Core 中更改电子邮件工作流答案

【问题标题】：Change email workflow in ASP.NET Core在 ASP.NET Core 中更改电子邮件工作流
【发布时间】：2019-10-01 19:36:29
【问题描述】：

如果用户想更改为新的电子邮件地址，我使用：

var token = await _userManager.GenerateChangeEmailTokenAsync(user, newEmail);

...并发送包含此更改令牌的确认邮件。用户单击电子邮件中的链接，返回站点，现在我需要更改电子邮件。

但是，我不知道新的电子邮件地址。

我经历了确认邮件循环的麻烦，所以我想使用它。再次询问电子邮件可能会导致输入错误，从而可能将用户锁定在其帐户之外，这也是用户面临的另一个障碍，我需要维护更多代码。

明显的解决方案：

再次请求（并冒着输入错误的风险，并使邮件循环毫无意义）
将新的电子邮件地址存储在User.NewEmailTemp 中（哎呀，想保持这个无状态）
将其包含在电子邮件的链接中（安全性差！）

可能有更好的方法。更改令牌包含一堆数据，其中包括一个包含新电子邮件地址的 “目的”。我可以以某种方式提取/解码目的，还是将其作为散列过程的一部分进行破坏？

【问题讨论】：

一些可能与我的系统无关的背景：1) 用户名是电子邮件地址，2) 使用 JWT 而不是 cookie，3) SPA（角度）。

标签： asp.net-core asp.net-identity asp.net-core-2.2

【解决方案1】：

答案就是坚持下去。无状态并不是一个真正的选择。但是，这并不意味着您必须用它污染用户子域。例如，您可以创建一个单独的实体，如 EmailChangeRequest，其中包含新电子邮件的道具、令牌，可能还有时间戳（主要用于修剪/到期）。此处的令牌不是用于验证，而是用于查找，因此可以将其视为表上的键。

总之，当用户单击链接时，您通过令牌查找请求，从中获取新电子邮件，然后使用该新电子邮件和令牌调用ChangeEmailAsync。

如果您真的反对任何形式的持久性，我之前曾亲自玩弄过 JWT 式的方法。我说“-esque”是因为将完全加密和签名的 JWT 作为查询或路由参数传递会为您的确认链接生成非常长的 URL，甚至可能接近请求限制。相反，我所做的是砍掉 JWT 的标头，因为标头主要用于跨客户端通信。在这种情况下，我可以放心地假设加密方法和发行者，这样是不必要的。

我所做的另一项更改是使用 TOTP 样式的令牌，而不是默认使用的加密哈希。这有助于进一步减少 JWT 令牌的大小，并且由于我正在对 JWT 本身进行加密，因此如果内部的令牌本身被加密，这并不重要。邮件确认之类的token provider可以是ConfigureServices中的easily customized，还有built-in TOTP token providers可以用，所以摩擦力也比较低。

我仍然认为保留它不一定是一件坏事，尤其是如果您在用户子域之外使用单独的实体。但是，如果您不想走这条路，伪 JWT 方法可能更适合您的需求。

【讨论】：

这里有很多好主意...非常感谢！单独的表是一个不错的快速修复，但小 JWT 的想法感觉更好。
我不明白为什么他们没有将电子邮件附加到更改令牌，作为签名标头的一部分，而不是将其编码到有效负载中。这样会更有用，因为它不会被篡改，但会揭示我们在这个工作流程中需要的关键信息。而且我看到他们刚刚编写的 3.0 代码并没有那样做。所以你的方法可能是我们会得到的赌注。
我认为那里的想法仍然是暴露的。只有有效载荷受到保护。标头必须对所有客户端可读，以协商签名令牌的加密和验证。如果它完全暴露，那么它也可能完全暴露 - 混淆不是安全 - 所以这种方法不会比仅仅添加到 URL 更好。
没错，但我的想法是邮件循环确保用户拥有该邮件，并希望执行更改。所以在那之后我不太担心以明文形式发送地址，我只想知道它在传输过程中不会被篡改。同意虽然有更安全的方式，就像你强调的那样，但我认为的方式是无状态的，相当安全，已知是准确的（因为我对其进行了编码），并且容易......但无法完成据我所知。
要考虑的不仅仅是简单的安全性。还有 PII。然而，我同意这也是相当少的，尽管有一些疯狂的立法来自欧盟，比如 GDPR，谁知道呢。至于你的问题，就留下吧。