MongoDB本地实例：应用用户与数据库用户登录设计抉择咨询

Hey there! Let's unpack your dilemma—using MongoDB's native database user system for your app's internal login feels like a convenient win at first, but those concerns about system collections are totally valid. Let's walk through the pros, cons, and the better approach here.

Why MongoDB's Built-in Users Seem Tempting #

• Ready-made authentication toolkit: You get out-of-the-box support for secure auth methods like SCRAM-SHA-256, plus built-in commands (db.createUser(), db.updateUser()) to manage roles and permissions. No need to build core auth logic from scratch.
• Native access control integration: If your app needs to restrict database-level access (e.g., certain users can only read specific collections), MongoDB's roles map directly to these operations, avoiding extra code for permission checks.

The Critical Downsides of Using System Collections for App Users #

Here's where the trouble starts—these system tools weren't designed for your app's end users:

• Rigid, unextendable structure: The admin.system.users collection has a fixed schema maintained by MongoDB. You can't easily add app-specific fields like nicknames, profile photos, signup dates, or user preferences without risking compatibility issues during MongoDB version updates.
• Misaligned permission granularity: Database roles control broad database/collection actions (read, write, create indexes), but app-level permissions are usually far more nuanced—like "can edit their own posts" or "access premium content." You can't map these business rules to MongoDB's native roles, forcing you to layer on extra logic anyway.
• Session management headaches: MongoDB's auth is connection-based. You'd need a separate database connection for every app user, which is impossible to scale (apps rely on connection pools). This disconnects database auth from your app's session system (JWT, cookies, etc.), creating unnecessary complexity.
• Operational overhead: Managing thousands of app users in a system collection gets messy. Bulk updates, user data exports, or backup/restore processes require specialized MongoDB admin commands instead of simple CRUD operations, making routine tasks more difficult.

The Better Approach: Build Your Own App User Collection #

The standard, scalable solution is to create a dedicated users collection for your app's end users:

• Fully customizable schema: Define exactly the fields your app needs—email, username, hashedPassword (use bcrypt/Argon2 for secure hashing), profile, createdAt, roles, etc. No restrictions, full flexibility.
• App-specific auth & permissions: Implement login logic with your preferred session system (JWT, server-side sessions), and handle business-level permissions using user document fields (e.g., roles: ['user', 'moderator']) or a separate permissions collection.
• Secure, separated database access: Have your app connect to MongoDB using a single, limited-permission database user (e.g., only has read/write access to your app's collections, not admin system collections). This keeps your database auth layer focused on protecting the database itself, while your app handles end-user auth independently.

Final Takeaway #

MongoDB's built-in user system exists to control who can access your database (developers, services, etc.), not to manage your app's end users. While it might save you a little time upfront, the long-term limitations will far outweigh the convenience. Building a custom user collection is the flexible, maintainable choice that scales with your app.

内容的提问来源于stack exchange，提问作者Guga Figueiredo