MongoDB认证方案选择：使用数据库用户还是自建用户表？

用MongoDB自带的用户角色体系做SAAS多租户的认证是安全可行的，只要你跟着官方安全规范走，适配好你的多租户场景，完全能替代自建用户表+Passport.js的方案。

• 自带权限隔离，精准控权：MongoDB的角色系统支持细到集合级的权限（比如只读、读写、仅能执行特定操作），每个客户一个独立库的情况下，你可以给主管理员分配对应库的全权限，组管理员给部分集合的读写，普通用户只给只读，从数据库层面就把跨租户的访问堵死了。
• 官方打磨的安全机制，少踩坑：MongoDB默认支持SCRAM-SHA-256加密存密码、TLS加密传输数据，还有审计日志可以追踪操作，这些都是经过大量生产环境验证的，比你自己写密码哈希、会话管理靠谱多了，避免自建时容易犯的低级安全错误（比如明文存密码、权限逻辑漏校验）。
• 减少重复造轮子的风险：自建用户表要处理的认证、权限逻辑，MongoDB原生已经帮你做了，你不用再花时间去补安全漏洞，能把精力放在业务逻辑上。

• 多租户管理有点繁琐：每个客户一个库，就得给每个库创建对应的用户和角色，手动肯定不行，得用Node.js写自动化脚本，创建租户时自动建库、建用户、分配角色，删租户时清理干净，不然时间久了会乱。
• 原生角色可能不够贴合业务：MongoDB的角色是基于数据库操作的（比如能不能插数据、能不能查数据），如果你的组管理员需要的是“只能管理自己组的用户”这种业务级权限，原生角色就覆盖不到，这时候要么用自定义角色扩展，要么在应用层再加一层校验。
• 容器化部署要盯紧配置：容器里的MongoDB一定要开--auth认证，不能裸奔，而且根用户密码不能硬编码在代码或镜像里，要用环境变量或者密钥管理工具存，不然泄露了就全凉了。

• 强制开认证和加密：部署时必须加--auth参数，同时配置TLS证书，禁止明文连接数据库，这是底线。
• 自定义角色适配业务：别直接用原生的read、readWrite，针对你的主管理员、组管理员等角色，创建自定义角色，比如给组管理员加“只能操作groups和users集合”的权限，精准匹配业务需求。
• 自动化用户生命周期：写个Node.js工具，客户注册时自动创建对应的数据库、用户和角色，客户注销时自动删除，全程自动化，减少人为错误。
• 应用层再加一道校验：比如普通用户只能看自己的数据，哪怕MongoDB给了他整个库的只读权限，应用层也要在查询时加userId过滤，双重保障，避免数据库权限配置出错导致的数据泄露。

内容的提问来源于stack exchange，提问作者Alex Knopp