Authentication 使用单一guid的匿名自定义登录-为什么不？

我想知道我是否可以就我正在考虑的一个宠物网站项目的简单身份验证系统征求意见，其中最重要的要求是该系统应该没有办法辨别用户是谁，也就是说，没有办法识别或联系他们

系统当然需要区分这些匿名用户，并防止用户冒充其他用户

也许在严格意义上，它根本不是一个认证系统，更像是一个区分系统

一个简单的解决方案是为新用户分配一个Guid，该Guid存储在cookie/本地存储器/任何东西中，并用于区分他们

然后为用户提供复制Guid的功能，和/或生成URL，用户可以将其作为书签或以其他方式存储在本地，通过使用生成的URL或将复制的Guid粘贴到站点上的“登录”页面，重新向站点提供Guid并将其存储为cookie（如果cookie被删除或他们希望从另一台计算机进行身份验证，则将使用）

这意味着不能有“我忘了我的密码”设施；如果用户丢失了他们的凭据，他们将永远丢失，这是可以接受的

此外，如果凭据被盗，或者用户的cookie被破坏，那么凭据将永远被盗，真正的用户无法锁定窃贼，这也是可以接受的

显然，用户需要确保将此URL/Guid存储在安全的地方，这是可以接受的

另一方面，可能有一种功能允许用户重新生成Guid，如果用户无意中以某种方式广播其Guid，则可能会使用该功能，但这也意味着如果有人在“真正”用户意识到之前窃取其Guid并使用重新生成功能，真正的用户将永远被锁定-也许最好它是不可更改的，所以至少如果Guid被破坏，小偷无法锁定真正的用户-但这是一个旁白

考虑到完全匿名/非接触性的要求，并接受失去Guid就像失去一张美元钞票一样，你永远失去它，这似乎是一个合理且令人愉快的简单解决方案

这与没有电子邮件地址或其他联系方式的用户/密码组合基本相同，但比用户更安全：sally123、密码：mydogsname1968或其他任何东西，因为它是一个Guid，而不是用户可以记住或在便笺上轻松涂鸦并粘在显示器上的东西

它还有一个优点，就是一直使用同一台机器（并且不删除cookie）的用户根本不需要登录或考虑凭据

Guid实际上可以是两个粘在一起的Guid，也可以是三个逐字节交错的Guid，不管怎样——一个独特的自动生成的数据块，反映了开发人员不必要的偏执情绪

有谁能告诉我，鉴于匿名性/非接触性要求和上述公认的缺点，为什么这不是一个好的解决方案，或者可能建议一个更好的解决方案

如果它对任何事情都有影响的话，它将是一个Net Core 5/Blazor Web Assembly/MongoDb应用程序，它是一个宠物项目，因此不必满足任何客户需求或现有系统等

---

谢谢您的建议/帮助。

只要是一次性使用，为什么不呢？但也许您应该研究JWTs和基于API的身份验证。您可以轻松地将其配置为要求用户名/密码登录一次（只要未清除cookie），然后在每次访问时刷新令牌。这是Blazor/WASM目前最常见的身份验证形式。谢谢，其目的不是一次性使用，我希望避免任何现有的API/OAuth等，并摒弃传统的用户/密码概念，将其替换为一个不可猜测的、唯一的、按定义的书签，它不会将您链接到任何其他内容，哪怕只是一点点——有点像锁的物理钥匙的数字等价物。你可以复制钥匙，而锁不知道谁在使用钥匙或钥匙是哪把钥匙——缺点是你可能会丢失钥匙或钥匙被盗；但是小偷不能用钥匙把你锁在外面。