Meteor Accounts 是面向 Meteor 3 应用的身份认证技能，基于 accounts-base 及各类认证风味包（accounts-password、accounts-google 等）构建。Meteor 将用户存储在 Meteor.users 集合中，并向客户端下发与该文档映射的 resume token。
用途与决策流程
该技能用于在 Meteor 3 应用中接入认证。选择方式如下：需要用户名加密码时添加 accounts-password；需要社交登录时添加 accounts-base 及对应提供商包（如 accounts-google）并配置服务；需要魔法链接时添加 accounts-passwordless；需要双因素认证时在 accounts-password 之上叠加 accounts-2fa。客户端令牌存储默认使用 Web Storage，Meteor 3.3+ 支持 HttpOnly Cookie 流程。若使用自定义 users 集合，需在应用读取或校验器运行前配置两个运行时；3.6 RC 修复了集合设置与发布查找，修改 profile 规则前应审查集合身份与客户端写入策略。
主要能力
用户名加密码：在服务端通过 Accounts.config 配置 sendVerificationEmail，并设置 Accounts.emailTemplates.siteName 与 from（from 地址必填，Meteor 3.5+ 若省略会记录服务端警告）。客户端在 Meteor 3.5+ 可使用 Accounts.createUserAsync 与 Meteor.loginWithPasswordAsync；旧版 3.x 可使用回调形式或包装为 Promise。服务端使用 await Accounts.createUserAsync(options) 与 await Accounts.setPasswordAsync(userId, newPassword)。注意：当客户端注册表单调用 Accounts.createUser 或 Accounts.createUserAsync 时，不要设置 forbidClientAccountCreation: true，否则服务端会以 403 Signups forbidden 拒绝；若为邀请制或管理员开通，需在客户端与服务端同时设置该选项，移除公开注册 UI，并仅在可信服务端代码中经自身授权检查后调用 Accounts.createUserAsync。
HttpOnly Cookie（Meteor 3.3+）：默认令牌存储为 Web Storage。要改为 HttpOnly Cookie 并让客户端标签页仅保留内存态，可在服务端 Accounts.config 中设置 clientStorage: "none" 与 useHttpOnlyCookies: true，并在 settings.json 的 public.packages.accounts 中暴露相同标志。重启并登录后，localStorage 中不再出现 Meteor.loginToken*，浏览器收到 HttpOnly 的 meteor_login_token cookie，每个标签页保留各自的内存凭据。DDP 认证仍会将 resume token 读入内存，因此这不能防御已在应用源中执行的恶意脚本。使用 accounts-base@3.3.1（Meteor 3.5.2）时，服务端也需选择加入才会处理 cookie 端点，仅客户端设置可能导致后续处理器返回 HTML 或 404；/set 请求体限制为 4096 字节，超出返回 HTTP 413。Meteor 3.6-beta.1 的 accounts-base@3.4.0-beta360.1 还要求可信来源与有效令牌，使用 SameSite=Strict，并新增按地址的端点速率限制；升级前应审查自定义调用方与跨站入口流程。RC 使用 accounts-base@3.4.0-rc360.0，重试或丢弃凭据前应区分无效会话与瞬时或限流响应。
OAuth（以 Google 为例）：服务端通过 ServiceConfiguration.configurations.upsertAsync 设置 clientId、secret 与 loginStyle（popup 或 redirect，移动端或无 window.close/window.opener 的环境用 redirect）。客户端调用 Meteor.loginWithGoogle。各提供商有独立包：accounts-google、accounts-github、accounts-facebook、accounts-twitter、accounts-apple、accounts-meetup、accounts-weibo。若需静态加密 OAuth 密钥，可添加 oauth-encryption 并向 Accounts.config 传入 oauthSecretKey，它会密封 ServiceConfiguration.configurations.secret 及受支持的提供商特定用户令牌字段，但不会创建通用的 Meteor.users.services.<provider>.secret 字段。
邮件验证与重置：客户端可调用 Accounts.forgotPassword、Accounts.resetPassword、Accounts.verifyEmail。可通过 Accounts.urls.resetPassword 与 Accounts.urls.verifyEmail 自定义邮件中的 URL 模式（Meteor 3.x 也接受异步函数），并通过 Accounts.emailTemplates 自定义主题与正文。
免密码登录：添加 accounts-passwordless 后，使用 Accounts.requestLoginTokenForUser 请求一次性验证码或链接，再用 Meteor.passwordlessLoginWithToken 提交验证码。仅登录流程可设置 userCreationDisabled: true。服务端可配置 tokenSequenceLength、loginTokenExpirationHours 及 Accounts.emailTemplates.sendLoginToken 模板。令牌请求方法属于易滥用端点，应对重复请求限流。
双因素认证：accounts-2fa 添加 TOTP。登录流程为：客户端在 Meteor 3.5+ 调用 Meteor.loginWithPasswordAsync，服务端以 error.error === 'no-2fa-code' 拒绝，客户端提示输入验证码后使用 Meteor.loginWithPasswordAnd2faCode 重试。
反模式
不要把 OAuth 密钥放在 Meteor.settings.public 中（客户端可见），应放在 settings.json 顶层。不要自行构建密码哈希，accounts-password 使用 bcrypt，应信任它。不要用接收密码的方法绕过 forbidClientAccountCreation。不要在延迟路径中运行 Accounts.config，应在顶层或 Meteor.startup 中调用。
适用场景与限制
适用于 Meteor 3 应用需要接入密码、社交、免密码或双因素认证的场景。限制与注意事项包括：HttpOnly Cookie 不能防御已在应用源中执行的恶意脚本；cookie 端点需服务端同时选择加入；/set 请求体上限 4096 字节；3.6-beta 与 RC 版本对可信来源、令牌有效性和速率限制有额外要求，升级前需审查自定义调用方与跨站入口。更多内容可参见 references/password-flows.md、references/oauth-services.md、references/eval-cases.md，OAuth 密钥加密与 CSP 参见 meteor-security 技能。