托管身份认证

这是什么

托管身份认证就是你应用的登录系统：注册、登录、密码重置、会话，以及让每个用户只能访问该看到的数据。在 ybuild 上，它被内置进每一个需要它的应用，用户因此获得真正的账户，而你完全不用碰任何安全代码。角色和权限会直接根据你的描述配置好。

为什么重要

一旦你的系统有了客户、员工或会员，它就必须分清谁是谁，并把每个人的数据彼此隔离、妥善保护。身份认证做错了，要么泄露数据，要么把人挡在门外——无论哪种都会摧毁客户对这门生意的信任。把它交给平台托管、做正确，才能让这套系统安全地交到真实用户手里。

在 ybuild 上怎么用

描述谁来登录、他们能看到什么，ybuild 就会把账户、会话和权限构建进这个正在运行的应用里。它托管在 ybuild 上，并通过你自己的域名对外提供服务，所以用户是在你的网址上登录，而不是某个第三方门户。敏感的凭据由平台负责存储和保护，不需要你手动管理。

ybuild 会把哪些东西接入你的登录系统

当你描述谁来登录时，ybuild 会构建完整的账户生命周期——注册表单、登录、通过邮件重置密码，以及让用户在应用里各处走动时保持登录状态的会话。这每一个步骤背后，都藏着一大堆很容易在细节上出错的安全细节。密码绝不会以用户输入时的原样被存储：平台会让每个密码经过一次慢速、加盐的单向哈希——正是 OWASP 明确规定的做法，使用 Argon2id 或 bcrypt——这样即便数据库有朝一日被泄露，里面也没有明文密码可拿。NIST 的现行指南同样塑造了登录所强制执行的规则：允许最长 64 个字符的长口令，抛弃那套只会逼出 Password1! 的老旧「必须包含特殊符号」的组合规则，并把新密码与已知的泄露密码库比对，而不是强制进行毫无意义的定期重置。

一旦有人登录，会话就会让他们保持登录状态，而不必每点一次都重新输入密码。ybuild 通过 HTTPS 下发这个会话，在登录的那一刻重新生成会话标识符，好让旧的标识符无法被重放，并让它在闲置超时和绝对存活时长两个维度上都会过期——这正是 OWASP 记录在案的会话卫生规范。退出登录会在服务器端让会话失效，而不只是关掉浏览器标签页而已。正是这些小细节，决定了一个账户会不会被劫持，而平台会替你处理好它们，而不是把它们当成一份留给你的清单。

身份认证不只是「这个人有没有登录」——更是「这个具体的人被允许看到什么」。当你告诉 ybuild：客户只看自己的记录、员工看自己经手的全部案件、而所有者看得到一切，它就会构建出这些角色，并在每一次读取和写入时强制执行，这样一个客户绝不可能靠改一改 URL 里的某个数字就调出另一个客户的数据。这种针对每个用户的隔离，是根据你的描述接入的，运行在 ybuild 上，并通过你自己的域名对外提供服务。

自己搭建身份认证，还是在 ybuild 上直接获得它

一个登录表单看起来像一下午就能干完的活，结果却变成了要花上一个季度的工程。看得见的部分——一个邮箱输入框、一个密码输入框、一个提交按钮——微不足道。真正的系统是它背后的一切：正确地对密码做哈希和加盐、生成密码重置令牌并让它过期、真正把重置邮件发出去、存储会话、在退出登录和修改密码时让会话失效、对失败的尝试进行限流，以及在生意有需要时加上第二重验证因素。每一块都有一种被明确记录下来的正确做法，和十来种悄无声息的错误做法，而这些错误做法并不会抛出报错——它们只是留下一个漏洞。

这些坑非常具体。NIST 要求有一套限流机制，把同一账户连续失败的尝试次数封顶在不超过 100 次，正是因为攻击者不会去猜某一个密码——他们会拿数以百万计被盗的密码轮番重放。Verizon 2025 年的泄露研究发现，在它所研究的机构里，撞库攻击占到全部登录尝试的中位数 19%，而被盗凭据是 22% 的泄露事件最初的入侵途径。一个永不过期的重置令牌、一个改了密码后依然有效的会话、一次只在页面上执行却没在其背后 API 上执行的权限检查——这里面随便哪一个，都是那种要等到被利用之后你才会发现、而不是之前的漏洞。

在 ybuild 上，这一切都不需要你亲手拼装。你描述谁来登录、每个角色能做什么，平台就会把账户、哈希、会话、重置、限流和权限检查构建进这个正在运行的应用里——没有身份认证库要配置，也没有安全代码要审查。它托管在 ybuild 上，并通过你自己的域名对外提供服务，因此凭据以受管密钥的形式存放在平台上，而你的用户是在你的网址上登录。日后当你要新增一个角色，或改变某人能看到的内容时，你只需用日常语言说一声，正在运行的应用就会就地更新。

托管身份认证对一门正在运营的生意意味着什么

当一套系统有了真实用户——客户在下单预约、员工在办公、会员在付费——的那一刻，身份认证就不再只是一项功能，而成了整门生意所依托的边界。它决定谁是谁，把一个人的数据与另一个人的隔开，并挡在你的记录与互联网上所有拿着被盗密码来碰运气的人之间。做对了，它就是隐形的；做错了，它就会以两种响亮的方式之一崩掉——要么是泄露，把客户数据暴露出去，要么是把付费用户挡在门外的封锁。无论哪一种，花掉的都是你很难轻易再挣回来的信任。

这种威胁并非假想。Verizon 2025 年的数据泄露研究把被盗凭据列在了机构遭到入侵的各种途径之首，而另有分析长期以来一直发现，针对日常 Web 应用的攻击中，绝大多数都是靠着某人手里早已握有的凭据混进来的。一家小生意的预约应用或 CRM，和一家银行处在同一张公共互联网上；唯一的区别在于，这个登录是由一个认真考虑过哈希、限流和逐用户访问的人搭建的，还是为了赶紧上线而胡乱拼凑起来的。托管身份认证意味着这些决定被一次性地、为每一个应用都做对了，并且由平台来维护，而不是由你在晚上 11 点亲自扛着。

说到实处，正是这一点让你敢把这套系统摆到它本该服务的人面前。客户拥有自己的账户，只看得到属于自己的预约、发票或记录；员工恰好拿到其角色所需的访问权限；而你手握全局的主视图。这一切都运行在 ybuild 上，并通过你自己的域名对外提供服务，所以登录感觉起来就是你生意的一部分，而不是绕道去某个第三方门户——那些敏感的部分始终存储并受保护在平台上，而不是散落在一张电子表格或某个你悄悄背着责任的旁路工具里。这正是「几个人随便试试的应用」和「一门真生意赖以运转的系统」之间的区别。

常见问题

我必须自己搭建登录系统吗？

不用。描述谁来登录、每个人各自该看到什么，ybuild 就会把整套东西——注册、登录、密码重置、会话，以及逐用户的权限——构建进这个正在运行的应用里。没有身份认证库要配置，也没有安全代码要你去写或审查。

我的用户密码存在哪里，安全吗？

存在 ybuild 上，而且绝不是明文。每个密码都经过一次慢速、加盐的单向哈希——正是 OWASP 推荐的做法——所以即便数据有朝一日被泄露，里面也没有真正的密码。凭据以受管密钥的形式保存在平台上，并通过你自己的域名对外提供服务。

不同的人可以有不同级别的访问权限吗？

可以。告诉 ybuild：客户只看得到自己的记录、员工看得到自己手头的全部工作、而所有者看得到一切，它就会构建出这些角色，并在每一次读取和写入时强制执行。一个用户没法靠改一改 URL 里的数字就调出另一个用户的数据，而且你日后随时可以用日常语言调整谁能看到什么。

有什么能阻止攻击者猜密码或重用被盗的密码？

登录会对失败的尝试进行限流，并按照 NIST 的指南把新密码与已知的泄露密码库比对——这一点很重要，因为在 Verizon 2025 年的泄露研究里，撞库攻击占到了登录尝试的中位数 19%。这层防护内置在每一个 ybuild 应用里，并由平台负责维护，而不是留给你自己去加。

我的用户是在我自己的域名上登录，还是在第三方页面上登录？

在你自己的域名上。账户、登录和会话都托管在 ybuild 上，并在你的网址上对外提供服务，所以登录感觉起来是你生意的一部分，而不是绕道去别人的门户。你的用户登录进去的那个应用，和他们信任的那个网站，是同一个东西。