我使用安全的单向哈希来在服务器上存储密码。我可以将此相同的哈希发送到客户端以用作令牌。
它应该是一个坚不可摧的单向散列（SHA-256或类似的），而且现在可以告诉它它来自用户密码或甚至知道它在那里除非你四处寻找。
如果这是O.K.寻找验证。 ？
如果它真的是一种方式，那么我假设你的服务器使用哈希而不是明文来验证登录。因此，发送密码哈希实际上与将密钥发送到您家的内门相同。还有一个外门，但为什么发送超过你需要/冒险。
您应该强烈考虑使用OpenID Connect来保护应用程序。 https://www.scottbrady91.com/OpenID-Connect/OpenID-Connect-Flows
OpenID Connect为Web应用程序提供有时间限制的授权代码。如果你很好奇为什么所有的间接和层，这个SO答案是有价值的：What is the difference between the 2 workflows? When to use Authorization Code flow?
总之，这不是一个坏主意。
不会。问题的严重程度取决于系统的其他细节，但无论如何这都是一个坏主意。
如果它是盐渍哈希，正确实现（哈希值之前的盐，每个用户的独特随机盐），那么单独的哈希就不会暴露密码。但是，密码很少更改，因此密码的哈希值很少会发生变化，因此截获此哈希值的任何人都可以使用它来无限期地模拟用户。
如果这个哈希没有被腌制，问题会变得更糟。拦截这样一个哈希的坏演员很有可能从中破解实际密码。无论技术上不可逆的散列算法如何，都有大量常见密码及其散列的数据库，并且对于许多用户来说，破解未加盐的散列只是数据库查找的一个简单问题。如果用户碰巧在许多网站上使用此密码，这很常见，这可能会变成全面的身份盗用。
您的想法的一部分是使用令牌进行身份验证。该令牌应该是纯粹随机的并且严格限时，但每次用户登录时都会生成一个新令牌。
道格拉斯指出，由于各种原因，这是不可能的。此外，如果您的用户发现这一点，您将极大地失去对您和您的产品的信任，并且可能会合法地伤害您，我非常确定这不是一个理想的选择:)。
我建议生成一个单独的令牌，它可能随着时间的推移而过期，并将其发送给它们。
此外，它实施起来相当简单，因此不小心谨慎。