Password vs Token vs API Key: When to Use Which
Passwords, tokens, and API keys serve different purposes. Here is when to use each.
Password vs Token vs API Key: When to Use Which
Passwords, tokens, and API keys all authenticate, but they serve different purposes. Here is when to use each.
Passwords
For human login. The user types their password, you verify it against a hash, and you start a session.
Use for: human login (web app, mobile app). Do not use for: service-to-service auth, API access from scripts.
Store: hashed with bcrypt or argon2. Never plain text.
Tokens (JWT)
For session continuity after login. The user logs in with a password, you issue a JWT, and the client includes the JWT in subsequent requests.
Use for: session after login, SSO, short-lived access to APIs. Do not use for: long-lived API access from third parties (use API keys).
Store: in httpOnly, secure, sameSite cookies for web. In secure storage for mobile.
Issue: with a short expiry (15 min) and a refresh token (longer, e.g., 7 days).
API Keys
For programmatic access from scripts, services, or third parties. A long string that identifies the caller and authorizes them.
Use for: service-to-service auth, third-party API access, CLI tools, cron jobs. Do not use for: human login (use passwords).
Store: hashed in the database, like passwords. Send the raw key once on creation; the user stores it. Compare hashes on each request.
Comparison
| Aspect | Password | Token (JWT) | API Key |
|---|---|---|---|
| Who | Humans | Humans (after login) | Services, scripts |
| Lifetime | Until changed | Short (15 min) | Long (or until revoked) |
| Stored where | Hashed in DB | In cookie or client | Hashed in DB |
| Sent how | Login form | Cookie or Authorization header | Header or query |
| Revocable | Change password | Expire or revoke | Delete or disable |
Combining Them
A common flow:
- User logs in with a password.
- Server issues a JWT (short expiry) and a refresh token (long expiry).
- Client uses the JWT for API calls.
- When the JWT expires, the client uses the refresh token to get a new JWT.
- For programmatic access (e.g., a CLI tool), the user generates an API key from their settings.
The Takeaway
Passwords for human login (hashed with bcrypt). Tokens (JWT) for session after login (short expiry, refresh token). API keys for programmatic access from services and scripts (hashed in DB, sent once). Use all three based on the use case.
Passwords for human login. Tokens (JWT) for session continuity after login. API keys for programmatic access from services, scripts, or third parties. Use all three based on the use case.
In an httpOnly, secure, sameSite cookie for web apps. In secure storage (Keychain, Keystore) for mobile apps. Do not use LocalStorage (open to XSS).
Hashed, like passwords. Send the raw key once on creation; the user stores it. Compare hashes on each request. If the database is leaked, attackers cannot use the hashes.
Short: 15 minutes for the access token. Use a refresh token (longer, e.g., 7 days) to get new access tokens. Short expiry limits the damage if a token is stolen.
No. Use API keys or mTLS. Passwords are for humans. Services do not type passwords; they use long random keys that do not expire on every request.
Ready to master Node.js completely?
Want to upskill yourself, crack your next interview, and get your dream job? Join our comprehensive course to dive deeper with high-quality video tutorials, solve interview questions, and a premium community.
Master Node.js
Want to upskill yourself, crack your next interview, and get your dream job? Join our comprehensive course.