身份认证:多端用户体系与登录模型 本章为身份认证专题的支柱页,讲解云开发 CloudBase 如何连接用户与数据。 章节摘要:身份认证是云开发 CloudBase 连接用户与数据的安全枢纽。它支持微信、手机号、邮箱、匿名等多种登录方式,并通过登录态令牌实现用户数据的隔离与授权。没有身份体系,数据库与存储的权限规则就无从谈起。本章梳理身份体系概览、登录流程与令牌机制、自定义登录与第三方接入,以及用户数据的隔离与授权。 学习目标 了解常见的登录方式及其适用场景 理解登录态与令牌的签发、校验与刷新机制 知道自定义登录与第三方接入的基本思路 掌握用户数据隔离与授权的落地方式 本章小节关系:第 5.1 节纵览身份体系;第 5.2 节深入登录与令牌机制;第 5.3 节扩展到自定义与第三方;第 5.
本章为身份认证专题的支柱页,讲解云开发 CloudBase 如何连接用户与数据。
章节摘要:身份认证是云开发 CloudBase 连接用户与数据的安全枢纽。它支持微信、手机号、邮箱、匿名等多种登录方式,并通过登录态令牌实现用户数据的隔离与授权。没有身份体系,数据库与存储的权限规则就无从谈起。本章梳理身份体系概览、登录流程与令牌机制、自定义登录与第三方接入,以及用户数据的隔离与授权。
学习目标
本章小节关系:第 5.1 节纵览身份体系;第 5.2 节深入登录与令牌机制;第 5.3 节扩展到自定义与第三方;第 5.4 节把身份与前面数据库的权限规则结合,完成「谁访问什么」的闭环。四节从「有哪些方式」到「如何鉴权」再到「如何隔离」。
身份认证回答一个根本问题:「当前是谁在使用应用?」云开发 CloudBase 提供多种登录方式,覆盖不同产品形态。
一旦应用要保存「属于某个用户」的数据,就必须先识别用户。身份体系是数据库权限规则、存储私有访问、个性化体验的共同前提。没有它,所有数据只能要么完全公开、要么完全私有,无法做到「我的归我、他人的不可见」。
不同方式对应不同的用户来源与信任等级。平台会把它们映射到同一套用户标识体系下,方便后续统一管理与数据归集。这意味着无论用户用哪种方式进来,业务层面对待的都是同一个「用户」概念。
选择时可以从「用户从哪里来、需要什么信任级别」出发:小程序优先微信,公网工具可用手机号或邮箱,访客预览则用匿名。多方式并存时,清晰的选型能减少后续账号碎片与维护成本。
无论哪种登录方式,背后大多遵循「凭证换令牌」的模式。
用户提交凭证(如验证码、授权码),平台核验通过后签发登录态令牌。此后客户端在请求中携带该令牌,云端据此识别用户身份并做权限判定。令牌代替了「每次都重交密码」的做法,既安全又方便。
令牌机制有几个关键设计:
在云函数侧,服务端可从请求上下文取出当前用户标识,并据此做更精细的业务校验。这正是第 2 章提到的「把敏感判断收口在服务端」的具体落地。
同一用户在多个设备登录时,令牌机制应能支撑各自独立的会话,同时在需要时支持登出或撤销。理解会话边界,有助于正确处理「登录过期、重新登录、跨端同步」等常见体验问题。
除了平台内置的登录方式,云开发 CloudBase 还支持把既有账号体系接入。
当你已有自有账号体系(例如既有的用户中心),可以签发自定义登录凭证,让原有账号无缝接入云开发环境。这样既能复用历史用户,又能享受云端资源的权限能力,是存量业务上云的常见路径。
第三方接入用于打通外部身份源,例如把其他开放平台的账号关联到当前应用。其要点在于:明确「以谁为主身份」,在关联后把外部标识映射到云开发的统一用户标识下。
良好的身份映射能避免同一用户产生多个碎片账号。做法通常是:以自有账号或主身份为锚,把各类外部登录方式绑定到同一用户标识;当用户首次用新方式登录时,提示其与已有账号关联,而非新建孤立账号。
身份认证的最终落点,是让「数据按用户隔离」。
结合第 3 章的数据库权限规则,典型做法是:在数据文档中记录创建者标识,权限规则规定「仅创建者可读写自己的文档」。这样同一个集合里存放所有用户的数据,却彼此不可见。
在前端直接读写时,权限规则以创建者标识为依据自动生效,无需你在每行查询里手动加过滤。把归属字段写对,隔离就自然成立。
在云函数侧,服务端可从请求上下文取出当前用户标识,并据此做更精细的业务校验,例如「只能修改自己发布的文章」「只能访问所属团队的文件」。即便函数拥有高权限,也应主动按用户边界过滤,而非把整张表 indiscriminately 暴露。
身份、权限规则、服务端校验三者协同,构成纵深防御:前端规则挡住多数越权,服务端校验补上关键业务的最后一道关。只依赖任何单一层都是危险的。
至此,用户体系与数据权限闭环完成。下一章我们将看到,前端如何经静态托管把这些能力组装成可访问的应用。
本章关键词:身份认证、CloudBase 登录、用户体系、登录态、自定义登录。下一篇:第 6 章 · 静态托管。