如何为你的应用添加登录：密码、魔法链接、Google和角色权限

要为应用添加登录，请先选择一种方式——邮箱加密码、魔法链接（通过邮件发送的一次性登录链接），或“使用Google登录”——并借助成熟的认证库或托管服务来实现，而不是从零开始编写。然后决定每类用户可以做什么（角色），并在每个页面和API请求中都在服务器端强制执行。会话应使用安全Cookie、设置过期时间，并在注销时正确结束。

本指南将逐一介绍每种选择，以及区分可用登录与安全登录的细节。关于其背后的概念，参见什么是身份认证。

首先决定：你真的需要登录吗？

登录会增加使用门槛，也会带来相应的责任。以下情况才需要登录：

• 用户拥有私人数据（他们的预订、文档、发票）
• 用户可以更改其他人会看到的内容
• 你对访问收费
• 不同的人需要不同的权限（所有者、员工、客户）

营销网站、公开目录或只会把内容发到你邮箱的表单，则不需要登录。候补名单不需要账户，一个邮箱字段就够了。

四种常见的登录方式

许多应用会组合两种方式：Google登录加邮箱魔法链接是一种流行的搭配，既能覆盖大多数人，又无需存储任何密码。

邮箱和密码

如果你提供密码登录，以下几点是必须遵守的：

• 使用慢速的密码哈希算法来哈希密码。 OWASP的密码存储指南推荐Argon2id，scrypt、bcrypt或PBKDF2可作为替代。切勿以明文形式存储密码，也不要使用快速的通用哈希。
• 密码重置使用随机的、一次性的、会过期的链接，并发送到已验证的邮箱。
• 不要泄露哪些邮箱已注册。 “如果该邮箱已注册，我们已发送重置链接”比“未找到账户”更好。
• 对登录和重置尝试进行速率限制，以减缓密码猜测。
• 允许较长的密码和密码管理器的使用；不要强制要求奇怪的字符组合规则。

魔法链接与一次性验证码

魔法链接是通过邮件发送给用户的登录链接，点击即可登录。一次性验证码是同样的思路，只不过是输入而不是点击。

• 链接和验证码应很快过期，并且只能使用一次。
• 链接应在用户点击的那台设备上完成登录，令牌不得留在日志或分析工具中。
• 你需要可靠的邮件发送能力，参见如何从应用发送邮件。请用Gmail和Outlook测试，并检查垃圾邮件文件夹。

使用Google登录（以及其他OAuth服务商）

“使用Google登录”基于OAuth和OpenID Connect：由Google确认用户身份，并把用户的邮箱和姓名告知你的应用。截至2026年9月，设置步骤位于Google Cloud Console的Google Auth Platform部分：

1. 创建或选择一个项目，并填写**Branding（品牌）**页面——即用户在同意屏幕上看到的内容（应用名称、支持邮箱、徽标）。
2. 在**Clients（客户端）**页面，创建一个类型为“Web应用”的客户端。
3. 添加你的已授权JavaScript来源和重定向URI——即你的应用运行的确切地址，以及Google在登录后将用户送回的地址。
4. 把客户端ID和客户端密钥保存到应用的密钥中。

根据Google的OAuth文档，以下问题常常会出现：

• redirect_uri_mismatch：重定向地址必须完全一致，包括 http 与 https、大小写以及末尾的斜杠。为预览地址和正式域名各添加一个。
• 必须使用HTTPS：重定向URI必须使用HTTPS，开发期间的 localhost 除外。
• 应检查 state 参数，以防止跨站请求伪造（CSRF）。优秀的库会为你完成这项工作。

如果你只请求基本的登录信息（姓名、邮箱、个人资料），Google表示应用验证并非强制要求。但请求访问用户的Gmail、云端硬盘或日历则不同，需要进行验证。

自建还是使用服务商？

前两种都是合理的选择。托管服务商为你处理得更多，但会增加依赖，并且有时按活跃用户收费；请在其官网查看当前价格。认证库把所有数据都留在你的数据库中，但需要你自己正确配置更多内容。无论选择哪种，都应让AI使用它，而不是手写密码或会话逻辑。

角色与权限

登录告诉你谁是用户，权限则决定他们能做什么。一开始保持简单即可：

比角色名称更重要的规则是：

• 每次都在服务器端检查。 在页面中隐藏按钮并不能阻止有人直接调用API。
• 按所有者限定范围。 会员请求“预订123”时，只有该预订属于他，才应返回结果。
• 用户不能自行提升权限。 对于资料更新，忽略从浏览器发送过来的角色字段。
• 默认不授予访问权限。 新增的路由应当要求登录，除非你明确决定不需要。

用两个账户来测试：用账户A登录，记下某条记录的ID，再用账户B登录并尝试打开它。我们的安全检查清单包含完整的测试方法。

会话安全

登录之后，应用会通过会话记住用户，通常是一个Cookie。OWASP的会话管理指南建议：

• 会话Cookie设置 Secure（仅HTTPS）、HttpOnly（页面脚本无法读取）和 SameSite
• 登录时签发新的会话ID，权限变化时也要重新签发
• 在服务器端强制执行空闲超时和绝对最长有效期
• 注销时在服务器端结束会话，而不仅仅是删除Cookie
• 用户修改密码后，会话失效

在浏览器的本地存储中保存登录令牌在教程中很常见，但它会把令牌暴露给页面上运行的任何脚本；对于Web应用来说，安全Cookie通常是更好的默认选择。

涵盖要点的提示词

为这个应用添加用户账户。用户可以使用邮箱和密码注册、登录，也可以使用Google登录。使用 [库或服务商]，而不是自定义的认证代码。使用Argon2id或bcrypt哈希密码。添加通过邮件进行的密码重置，使用一次性链接，一小时后过期。把会话保存在安全的、HttpOnly的Cookie中。保护 /dashboard 以及每一个 /api 路由，使只有登录用户才能使用，并确保用户只能看到自己的项目。添加一个可以查看所有用户的“admin”角色；只有管理员才能访问 /admin，并在服务器端进行检查。

然后进行测试：注册、注销、登录、重置密码，在未登录状态下尝试访问私有URL，并尝试访问另一个用户的记录。

AI构建登录的常见错误

• 保护只存在于页面中。 页面会把未登录用户重定向走，但API仍然会把数据返回给任何人。
• 密钥出现在浏览器中。 OAuth客户端密钥和认证服务商的管理员密钥应当放在服务器上。
• 预览与正式地址混淆。 Google的重定向URI或重置邮件中的链接指向预览地址，因此发布后登录就失效了。
• 没有邮箱验证。 任何人都能注册为 anyone@company.com。在授予与该邮箱绑定的任何权限之前，应先验证邮箱。
• 只测试正常流程。 请尝试错误密码、过期链接以及第二个账户。

在Mythex中添加登录

在Mythex中，为你应用的用户添加登录是你在应用中要做的事，它与你自己的Mythex账户是分开的。Mythex不提供内置的认证产品，因此你需要引入认证库或服务商及其密钥：

1. 选择一种方式，例如把邮箱和密码存储在你自己的数据库中，或使用托管服务商的SDK。
2. 如果你自己存储用户，应用就需要数据库；在聊天中要求创建，或使用 /database。
3. 把服务商密钥放入项目密钥（/secrets 或项目设置）。
4. 使用类似上面的提示词，然后在预览中测试。对于Google登录，要同时为预览地址和已发布地址添加重定向URI。

参见文档中的为应用添加登录。如果你正在构建一款付费产品，如何构建SaaS MVP会同时介绍账户和计费。

常见问题