什么是身份验证的最佳实践？为什么？
您无需自行实现身份验证。
你不应该自行实现身份验证。
OAuth2 的设计方式和原因
身份验证不仅仅是身份验证
您无需自行实现身份验证。
Clerk是一款适用于 React 的即插即用型身份验证和用户管理解决方案，几个月前完成了 1500 万美元的 A 轮融资。如果您对这笔融资没有特别强烈的感受，可以看看它的用户增长曲线，以此来了解它目前的受欢迎程度。
如果您无法接受使用外部服务进行所有用户管理，还有许多其他身份验证库可供选择。其中最受欢迎的是NextAuth，其在 GitHub 上的星标数量不断增长就证明了这一点。
这种趋势的明显原因是它们都为身份验证过程提供了很好的抽象层。开发人员现在只需进行一些配置设置，然后一切都能以最佳方式运行。
在表面之下，还有另一种观点支持这种趋势。
你不应该自行实现身份验证。
简而言之：一切都与安全有关。
开发安全可靠的身份验证系统需要深入理解安全原则、加密协议和最佳实践。即使是实施过程中的微小错误也可能导致严重的安全漏洞，危及用户数据安全。当系统与第三方交互时，这一点尤为重要，例如第三方身份验证（OAuth），这几乎是 Web 应用程序的标准做法。
通过利用现有的身份验证库或服务，开发人员可以从行业最佳实践中受益，同时最大限度地降低与自定义实现相关的风险。
你可能会有不同的看法，特别是如果你自己实现过的话。那么，让我们用 OAuth2 做个测试，看看你对它的理解程度如何。😄
OAuth2 的设计方式和原因
我认为大多数人都能轻松准确地用下图展示 OAuth2 的工作流程，甚至可以添加更具体的细节：
然而，您是否知道这种广为人知的流程实际上是 OAuth2 的四种授权类型之一，具体来说是授权码授权类型？如果您不知道，也情有可原，因为它是最安全的方式。因此，其他三种方式在实际应用中很少使用。无论如何，请思考以下问题：
为什么不直接返回访问令牌，而要费劲编写代码呢？
大多数人都能看出，如果这样做，攻击者可以通过将重定向 URL 设置为指向自己的服务器来窃取访问令牌。虽然这没错，但您是否知道，现在大多数身份验证提供商都提供了设置直接 URL 白名单的功能，例如以下示例：
如果我仅允许重定向 URL 到我们自己的网站，问题还会出现吗？
如果您未使用加密连接（HTTPS），则可能会遭受中间人攻击，导致访问令牌被读取。您可能会问，现在还有谁会用HTTP？然而，在早期阶段，要求所有开发者购买SSL证书并在其域名上正确配置SSL将非常麻烦，并会极大地减缓HTTP的普及速度。在早期测试阶段，这对于一些开发者来说可能仍然是一个负担。
如果使用非对称加密来加密 access_token，使其只能使用 client_secret 解密，会怎么样？
这似乎是一个可行的解决方案。然而，出于安全考虑，或许最好只传输一次性使用的中间“授权码”，且只有预期的接收者才能交换该授权码（因为需要客户端的密钥）。即使潜在的黑客成功拦截了网络交易，由于他们没有客户端的密钥，这个授权码对他们来说也毫无用处。
此外，强制应用服务器和授权服务器之间进行后端通信，可以提供更多进行安全检查的机会。
身份验证不仅仅是身份验证
以上内容均指身份验证（AuthN），身份验证的另一部分是授权（AuthZ）。您可以在下方找到更详细的解释：
如果您曾经实施过 SaaS 产品，您可能知道授权 (AuthZ) 比身份验证 (AuthN) 要复杂得多。处理多租户隔离、软删除、组共享以及混合使用基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC) 等问题，都可能使授权成为您业务逻辑中最复杂、最容易出错的部分。
为了在授权方面实现与 Clerk 和 NextAuth 在身份验证方面相同的便捷性，我们创建了ZenStack：一个 TypeScript 工具包，它通过强大的访问控制层增强了 Prisma ORM 的功能。您可以使用访问策略将授权问题集中到模式中，从而获得以下优势：
- 更小的代码库。
- 与手动编写授权逻辑相比，这种方法更加安全可靠。
- 更好的可维护性，因为当授权规则发生变化时，只需要在架构中进行更改即可。
如果您感兴趣，可以在下面的帖子中找到一个示例项目：
ZenStack是我们开源的 TypeScript 工具包，旨在帮助您更快、更智能、更高效地构建高质量、可扩展的应用程序。它将数据模型、访问策略和验证规则集中到一个基于 Prisma 的声明式模式中，非常适合 AI 增强型开发。立即开始将ZenStack集成到您现有的技术栈中吧！
文章来源：https://dev.to/zenstack/whats-the-best-practice-for-auth-and-why-3a60