Web应用的认证与授权

认证与授权：你是谁，你能做什么？

身份验证是确认某人身份的过程——通常通过用户名和密码、社交登录或指纹。授权是关于允许该人做什么——他们可以访问哪些页面，执行哪些操作。对于任何有用户的应用程序来说，两者都是必不可少的。

身份验证如何工作

传统方法使用会话。登录时，服务器在数据库或缓存中创建会话记录，并向浏览器发送包含会话ID的Cookie。在后续请求中，浏览器发送Cookie，服务器查找会话以确定您的身份。这种方法简单且安全，但需要服务器端存储。

更现代的方法使用JSON Web令牌（JWT）。登录时，服务器创建一个包含您的身份和权限的签名令牌。令牌发送给客户端，客户端存储它并在每个请求中发送它。服务器无需在数据库中查找任何内容即可验证令牌——令牌本身包含信息。这是无状态的，扩展性好，但令牌不容易撤销。

OAuth 2.0和社交登录

OAuth 2.0是允许您使用Google、GitHub或其他提供商登录的标准。您的应用程序将用户重定向到提供商，提供商请求权限。如果用户授予权限，提供商返回一个代码，您的应用程序将其交换为令牌。这比自己处理密码更安全，用户也喜欢不必再创建另一个帐户。

OpenID Connect在OAuth 2.0之上添加了一个身份层，提供了一种标准化的方式来获取用户的个人资料信息。大多数现代身份验证系统都实现了两者。

多因素认证

仅靠密码是不够的。人们重复使用密码、陷入网络钓鱼陷阱并使用弱密码。多因素认证（MFA）增加了第二层安全保护。最常见的形式是来自身份验证应用程序的基于时间的一次性密码（TOTP）。更安全的是硬件安全密钥和通行密钥，它们能够抵御网络钓鱼并且无法被猜测。

授权：控制访问

一旦知道某人是谁，就需要决定他们能做什么。最简单的模型是基于角色的访问控制（RBAC）：用户具有管理员、编辑者或查看者等角色，每个角色具有特定权限。更灵活的模型包括基于属性的访问控制（ABAC），它考虑用户、资源和环境的属性来做出决策。

使用身份验证提供商

从头构建身份验证既复杂又危险。像Auth0、Clerk和Supabase Auth这样的现代提供商处理了困难的部分——密码哈希、会话管理、社交登录、MFA和安全监控。它们提供了与前端和后端集成的SDK，并且开箱即用地处理安全最佳实践。对于大多数项目，使用提供商是正确的选择。