JWT令牌应存入多少用户档案数据？Node+Express API实践咨询

Let’s break this down step by step—this is such a common and important question when building secure APIs with JWT, especially since you’re already thinking about balancing token utility, size, and security.

1. Recommended Fields to Include in Your JWT Payload (Based on Your Schema) #

Given your Mongoose User schema, here’s what I’d recommend including, and why:

• _id: Non-negotiable. This is your unique identifier for fetching the full user record from the database whenever you need additional data (like img, email, or updated user details). It’s tiny, essential, and never changes.
• role: Critical for route protection. Instead of hitting the database every time to check if a user has permission to access an endpoint (e.g., /admin/dashboard), you can validate the role directly from the JWT payload. This cuts down on unnecessary DB calls and speeds up authorization checks.
• userName: Optional but highly useful. If your frontend needs to display the user’s name quickly (e.g., in a navigation bar), including this avoids making an extra API call to fetch user details on every page load. Since usernames usually don’t change often, this is a safe addition.

What to Leave Out #

• img: You’re right to skip this—image URLs can be long, and adding them bloats the token unnecessarily. Fetch it from the database using the _id when you need it (e.g., on a user profile page).
• email: Unless your frontend needs to display the email immediately (and it rarely changes), leave this out. Emails can be updated, and JWTs are immutable once issued—if a user changes their email, any existing tokens will have outdated data. Plus, if you’re avoiding fine-grained PII, email falls into that category for many use cases.

2. Does JWT Size Impact Performance? #

Short answer: Yes, but only when the token gets excessively large. Here’s what to watch for:

• HTTP Header Limits: JWTs are sent in the Authorization header. Most servers (like Nginx) have default limits for header size (usually around 4KB). If your token grows beyond this, requests will fail with a 413 Payload Too Large error.
• Bandwidth & Latency: Every request carries the JWT. A bloated token increases the size of each request, which adds up especially for mobile users or high-traffic APIs.
• Parsing Overhead: While parsing a small JWT is negligible, a large one adds tiny but cumulative time to each request’s processing.

The good news: If you stick to just _id, role, and userName, your token will be extremely small (well under 1KB base64-encoded), so you won’t hit any of these issues.

3. Established Best Practices to Standardize On #

To keep things consistent and secure, follow these rules:

• Only store static, non-sensitive data: Never include passwords, API keys, or any data that could compromise the user if the token is leaked.
• Keep payloads minimal: Err on the side of smaller—if you can fetch a piece of data from the database when needed instead of storing it in the JWT, do that.
• Use short-lived access tokens: Pair your JWT with a refresh token. Access tokens should expire quickly (15-60 minutes), so even if they’re stolen, the window of misuse is small. When the access token expires, use the refresh token to get a new one with updated user data.
• Validate the signature always: Even though you’re trusting the payload for quick checks, never skip verifying the JWT signature on every request—this ensures the token hasn’t been tampered with.
• Avoid storing mutable data: If a field can change (like email or profile picture), don’t put it in the JWT. Fetch it from the database when you need the latest value.

内容的提问来源于stack exchange，提问作者Solomon Bush