基于NodeJS的移动端API后端是否需使用JSON Web Tokens？求建议
Hey Kevin, let’s break down your questions about authentication for your mobile backend—this is super important to get right for both security and scalability.
问题一：是否仅需为移动端API后端创建JSON Web Tokens？
JWT is absolutely a fantastic primary choice for mobile API authentication, though it’s not the only option—but it’s by far the most widely recommended for modern mobile apps. Here’s why it fits so well:
- It’s stateless: Your backend doesn’t have to track active sessions in a database or cache. This makes scaling way easier, since you don’t need to sync session data across multiple servers if you grow.
- It’s self-contained: You can tuck small, non-sensitive user details (like their ID, role, or token expiration time) right into the token. That cuts down on extra database lookups for every API request.
- Mobile-friendly: Unlike cookie-based sessions (common in web apps), JWTs are sent via HTTP headers (usually
Authorization: Bearer <your-token>), which works seamlessly with how mobile apps make API calls.
That said, most teams pair JWTs with refresh tokens—longer-lived tokens that let users get a new JWT when their original short-lived one expires. This balances security (short JWT windows limit damage if a token is stolen) and user experience (no repeated logins). But at its core, JWT should be your main authentication tool here.
问题二：当前用UserDefaults存储用户ID发起请求的方案，是否需要换成JWT？
Yes, you absolutely should replace this setup with JWT (or another secure authentication method). Here’s the big problem with your current approach:
- Storing and sending a static user ID means anyone who gets that ID (whether via intercepted traffic or a compromised device) can impersonate the user forever. Your backend has no way to verify that the request is actually coming from the legitimate user—anyone with the ID can make requests on their behalf.
JWT fixes these security gaps by:
- Being cryptographically signed: Your backend can check that the token was issued by you and hasn’t been tampered with. If someone tries to alter the user ID in the token, the signature will fail, and you can reject the request.
- Having built-in expiration: You can set short expiration times (15-60 minutes is standard) so even if a token is stolen, it’s only usable for a limited window.
- Supporting secure storage: On iOS, you should store JWTs in the Keychain instead of UserDefaults. UserDefaults stores data in plaintext, which is a huge security risk—Keychain encrypts data and is far more resistant to device-level attacks.
Quick implementation tips for your Node.js backend:
- When a user logs in successfully, generate a JWT with libraries like
jsonwebtoken. Include the user ID and an expiration time in the token payload. - Send the JWT (and a refresh token, if you’re using them) back to the iOS app.
- Have the iOS app attach the JWT to every subsequent API request in the
Authorizationheader. - Add middleware to your Node.js routes that verifies the JWT’s signature and checks if it’s expired before processing the request.
内容的提问来源于stack exchange，提问作者KevinVuD
