Django Rest Framework认证选型困惑：移动及React前端API该选哪种？

Hey there, let's unpack this clearly since you're building for iOS/Android apps plus a future React frontend—authentication choices here are all about balancing security, usability, and maintainability. I’ve helped a lot of devs navigate this exact dilemma, so let’s break it down:

You’re using DRF’s built-in Token Authentication, where a single token is stored in your database and saved locally on clients. The big red flag here is that by default, these tokens don’t expire—if one gets leaked (say, via a malicious app on mobile or XSS on web), an attacker can use it indefinitely until you manually revoke it by deleting the token from your database. That’s a huge security gap for user accounts.

JWT gets recommended because it fixes some of DRF Token’s pain points:

• It’s stateless: No need to hit the database every time to validate a token—you just decrypt it using your secret key.
• Built-in expiration: You can issue short-lived access tokens (15-30 mins) paired with longer-lived refresh tokens, limiting the window of risk if a token leaks.

But you’ve likely run into its annoying drawbacks:

• No easy revocation: Once a JWT is signed, it’s valid until it expires—you can’t just “turn it off” if a user logs out on one device, changes their password, or gets hacked.
• Storage risks: Just like DRF’s token, storing JWTs in mobile SharedPreferences/iOS UserDefaults or web localStorage exposes them to theft (XSS for web, malicious app access for mobile if stored insecurely).
• Bulkier payload: JWTs carry all their claims (user ID, permissions, etc.) in the token itself, so they’re larger than DRF’s compact tokens—minor, but adds up with high request volume.

For mobile + React, the sweet spot is short-lived JWT access tokens + long-lived refresh tokens, with fixes to mitigate JWT’s biggest flaws. Here’s how to pull it off:

3.1 Fix JWT’s revocation problem #

• Use a refresh token blacklist: When a user logs out, changes their password, or needs to be forced offline, add their refresh token to a blacklist (use Redis for this—it’s fast and lets you set expiration matching the refresh token’s lifespan). Every time a client uses a refresh token to get a new access token, check the blacklist first.
• Since access tokens are short-lived (15 mins max), even if you can’t revoke them immediately, the window of opportunity for an attacker is tiny—way better than a permanent DRF token.

3.2 Secure token storage properly #

• Mobile: Never store tokens in plaintext SharedPreferences (Android) or UserDefaults (iOS). Use your platform’s secure storage: Android’s EncryptedSharedPreferences or Keychain, iOS’s Keychain Services. These are encrypted and only accessible to your app.
• React: Ditch localStorage for refresh tokens—store them in HttpOnly, Secure cookies. Access tokens can live in memory (re-fetch with the refresh token when the page reloads). HttpOnly cookies can’t be accessed by JavaScript, so XSS attacks can’t steal them.

3.3 If you really don’t want JWT: Improve DRF’s built-in Token #

If JWT feels too complex, you can patch DRF’s Token Authentication to be safer:

• Add an expires_at field to the Token model and build a custom authentication class that checks if the token is expired.
• Implement a revocation system (either mark tokens as inactive in the database or use a Redis blacklist).
• The catch? Every request still needs to hit your database to validate the token, which can hurt performance at scale—something JWT avoids.

If you go the JWT route, use the battle-tested djangorestframework-simplejwt package—it handles all the heavy lifting for access/refresh tokens, rotation, and blacklisting (just pair it with Redis). Here’s a quick config snippet to get you started:

# settings.py
from datetime import timedelta

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'rest_framework_simplejwt.authentication.JWTAuthentication',
    ),
}

SIMPLE_JWT = {
    'ACCESS_TOKEN_LIFETIME': timedelta(minutes=15),
    'REFRESH_TOKEN_LIFETIME': timedelta(days=7),
    'ROTATE_REFRESH_TOKENS': True,  # Issue new refresh token when getting a new access token
    'BLACKLIST_AFTER_ROTATION': True,  # Blacklist old refresh tokens
}

For clients:

• Mobile apps: Send the access token in the Authorization: Bearer <token> header. On 401 responses, use the refresh token to fetch a new access token automatically.
• React: Use an interceptor to attach the access token to requests. When a 401 hits, send a request to the refresh endpoint (which uses the HttpOnly cookie) to get a new access token.

内容的提问来源于stack exchange，提问作者J. Hesters