I'm building an app with token-based auth and need abuse prevention

Got it. For a token-based auth app, abuse prevention usually needs a layered approach, because tokens alone don’t stop scraping, credential stuffing, account takeover, or automated abuse.

Here’s a practical framework you can implement.

1) Protect authentication endpoints

These are the highest-risk routes:

• POST /login
• POST /signup
• POST /forgot-password
• POST /refresh-token
• POST /verify-otp

Add:

• Rate limiting per IP, per account, and per device fingerprint if possible
• Progressive delays after repeated failures
• Account lockout or step-up checks after suspicious behavior
• CAPTCHA only after risk is detected, not on every request
• MFA for sensitive accounts or actions

Example limits:

• Login: 5–10 attempts per minute per IP
• Password reset: 3–5 per hour per account/email
• Token refresh: limit unusually frequent refreshes
• Signup: limit by IP, subnet, email domain, and device

2) Use strong token design

For access tokens:

• Keep them short-lived: 5–15 minutes
• Prefer opaque tokens or JWTs with short TTL
• Don’t put sensitive data in JWTs
• Include:
  • sub user id
  • exp expiration
  • iat issued at
  • aud audience
  • iss issuer
  • optional jti unique token id

For refresh tokens:

• Use longer-lived refresh tokens with rotation
• Store refresh token hashes server-side if you need revocation
• Detect reuse of old refresh tokens and revoke the whole session family
• Bind refresh tokens to a device/session identifier if feasible

3) Add request-level abuse controls

Apply limits beyond auth endpoints:

• Per-user API rate limits
• Per-IP limits
• Per-token limits
• Burst + sustained limits
• Endpoint-specific limits for expensive operations

If you have a public API, consider:

• Different limits by plan/tier
• Quotas per day/hour
• Global circuit breakers for abuse spikes

4) Detect suspicious patterns

Look for:

• Many failed logins from one IP
• Many accounts from one device/IP
• Rapid token refreshes
• Token use from multiple geographies in a short time
• Unusual user-agent changes
• High-volume enumeration of usernames/emails
• Repeated 401/403s followed by success

Useful signals:

• IP reputation
• ASN / proxy / VPN / datacenter detection
• Device fingerprint
• Session anomaly scoring
• Velocity checks:
  • too many signups per minute
  • too many password resets
  • too many actions per session

5) Use step-up authentication

For risky actions, require extra verification:

• Change password
• Change email
• Withdraw money / delete data
• Add API keys
• Disable MFA
• Export data

Step-up methods:

• Re-authentication with password
• OTP / TOTP
• WebAuthn / passkey
• Email confirmation for lower-risk actions

6) Harden token storage and transport

• Always use TLS
• Store tokens in secure storage:
  • Web: prefer HttpOnly + Secure cookies for refresh tokens
  • If using localStorage for access tokens, be aware of XSS risk
• Set cookie flags:
  • HttpOnly
  • Secure
  • SameSite=Lax or Strict when possible
• Rotate signing keys carefully if using JWTs
• Validate issuer, audience, expiration, and signature on every request

7) Implement revocation and session management

You need a way to stop bad actors quickly:

• Maintain a session store or denylist for revoked refresh tokens
• Allow users to view and revoke active sessions
• Revoke all sessions on password reset or suspected compromise
• Invalidate tokens after MFA changes or email changes
• Support global logout

8) Prevent account enumeration

Don’t reveal whether an email/username exists:

• Use generic login errors
• Use consistent timing where possible
• For password reset, always respond with the same message
• Rate limit signup/login lookup endpoints

Bad:

• “No account found for that email” Good:
• “If the account exists, we sent a message.”

9) Add bot mitigation

Depending on your abuse level:

• CAPTCHA or Turnstile after risk triggers
• Device attestation if mobile
• Headless browser detection
• IP reputation / proxy detection
• WAF rules for known bad patterns

10) Log and alert

Log:

• Auth attempts
• Token issuance/refresh/revocation
• Rate-limit hits
• Suspicious geolocation changes
• MFA failures
• Password reset requests

Alert on:

• Spike in 401/403
• Spike in signup/login failures
• Large token refresh volume
• Reused refresh token detection
• Unusual admin activity

Be careful not to log secrets:

• Never log full tokens
• Never log passwords or OTPs
• Mask PII where possible

11) Consider risk-based policies

You can dynamically adjust controls:

• New device → extra verification
• New country → step-up auth
• Suspicious IP → stricter rate limits
• High-value accounts → always require MFA

12) Common secure defaults

A solid baseline:

• Access token: 10 min TTL
• Refresh token: 30 days, rotating
• Login rate limit: 5/min/IP and 10/hour/account
• Password reset: 3/hour/account
• Session revocation on password change
• MFA for admins and privileged actions
• Audit logs for all auth events

If you want, I can help you design:

1. a JWT/refresh-token architecture,
2. a rate-limiting policy table, or
3. a Node/Python/Go implementation for abuse prevention.