🔐 How to Prevent Expired JWT Token Reuse and API Authorization Bypass?

I’m looking for suggestions from developers, security engineers, and penetration testers who have handled similar issues in production applications.

I recently came across an interesting security scenario involving JWT token reuse, session termination, and Burp Suite response manipulation.

---

1️⃣ The Scenario

My application has:

• ⚛️ React frontend
• ☕ Spring Boot backend
• 🔑 JWT-based authentication
• 🌐 HTTPS
• 🛡️ Role and permission-based authorization

During security testing, the tester captures a valid access token and attempts to reuse it after the token has expired or the session has been terminated.

Expected behavior

User Login
    ↓
Access Token Issued
    ↓
Token Expires / Session Terminates
    ↓
Old Token Becomes Invalid
    ↓
Attacker Replays Old Token
    ↓
Backend Rejects Request

The main requirement is:

An expired, revoked, or terminated token must never be accepted for a protected API operation.

---

2️⃣ The Interesting Part — Burp Suite

There is another aspect that makes this scenario interesting.

Suppose the backend correctly identifies the token as invalid and returns:

HTTP/1.1 401 Unauthorized

The tester can intercept the response using Burp Suite and change it to:

HTTP/1.1 200 OK

before the response reaches the React application.

Flow

Attacker
    ↓
Expired / Invalid Token
    ↓
Spring Boot
    ↓
401 Unauthorized
    ↓
Burp Suite
    ↓
401 → 200
    ↓
React receives modified response

I understand that the browser is an untrusted environment and that an attacker controlling their browser can modify HTTP requests and responses.

However, my question is:

What is the industry-standard approach to ensure that this type of manipulation cannot result in an actual unauthorized server-side operation?

---

3️⃣ What I Have Already Considered

🔑 Authentication

• Short-lived access tokens
• JWT signature validation
• JWT expiration validation
• Refresh-token rotation
• HttpOnly + Secure cookies

🚫 Token / Session Management

• Server-side session invalidation
• Token/session versioning
• Token revocation
• Invalidating previously issued tokens after logout

👮 Authorization

• Permission validation on every protected API
• Role-based authorization
• Server-side authorization
• Never trusting frontend role/permission information

---

4️⃣ Token Replay Scenario

For example, suppose an attacker captures:

Token A

Later:

Token A
   ↓
Expires / Session Terminated
   ↓
Attacker Replays Token A
   ↓
Protected API

The backend should independently validate:

JWT Signature
      ↓
Expiration
      ↓
Session Validity
      ↓
Token Status
      ↓
User Status
      ↓
Permission
      ↓
Business Authorization

Only if all validations succeed should the operation be performed.

---

5️⃣ Expected Security Model 🛡️

Attacker Captures Token A
          ↓
Token A Expires / Session Terminates
          ↓
Attacker Replays Token A
          ↓
Backend Independently Validates
          │
          ├── 🔑 JWT Signature
          ├── ⏳ Expiration
          ├── 🔒 Session Validity
          ├── 🚫 Token Status
          ├── 👤 User Status
          └── 👮 Authorization
                  ↓
               REJECT
                  ↓
       Protected Operation NOT Performed

---

6️⃣ JWT vs Session-Based Authentication

This also raises an architectural question.

Approach	Token Revocation	Replay Protection	Complexity
Long-lived JWT	Hard	Weak	Low
Short-lived JWT	Better	Better	Medium
JWT + Server-side Session	Strong	Strong	Medium
Opaque Session Token	Strong	Strong	Medium

---

7️⃣ Refresh Token Replay 🔄

Another area I am particularly interested in is refresh-token reuse.

Refresh Token A
      ↓
Refresh Request
      ↓
Token A Invalidated
      ↓
Refresh Token B Issued
      ↓
Attacker Reuses Token A
      ↓
Replay Detected
      ↓
Reject / Terminate Session

What is the recommended production approach for detecting and handling this type of refresh-token replay?

---

8️⃣ My Questions to the Community ❓

1. What is the recommended architecture for preventing JWT replay/token reuse after logout or session termination?
2. Is JWT alone appropriate when immediate token invalidation is required?
3. Should access tokens be short-lived with refresh-token rotation?
4. What is the recommended way to invalidate previously issued access tokens?
5. How should a backend detect and handle refresh-token replay?
6. Would opaque/session-based tokens be a better alternative when strong revocation is required?
7. From a penetration-testing perspective, what is the standard remediation when a previously issued token can still be reused?
8. If the backend correctly returns 401 but Burp changes it to 200 before it reaches React, is there an accepted way to prevent the frontend from trusting the manipulated response?

---

9️⃣ The Important Distinction

I understand that these are two different scenarios:

Scenario A — Response Manipulation

Backend
   ↓
401 Unauthorized
   ↓
Burp Suite
   ↓
401 → 200
   ↓
React

This may fool the client-side UI, because the browser is controlled by the attacker.

Scenario B — Actual Authorization Bypass 🚨

Expired / Revoked Token
        ↓
Protected API
        ↓
Backend Accepts Request
        ↓
Unauthorized Operation Executed

My primary concern is Scenario B.

Even if an attacker can manipulate the frontend or HTTP response, the backend should remain the final security boundary and must never perform an unauthorized operation.

---

🔟 What I Am Looking For

I would particularly appreciate feedback from people who have:

• 🛡️ Handled penetration-testing findings
• 🔐 Designed authentication/session architectures
• ☕ Implemented Spring Security
• ⚛️ Secured React applications
• 🏢 Built authentication systems for production applications

I’m interested in real-world solutions and architecture patterns, rather than only theoretical recommendations.

Tech Stack: ⚛️ React + ☕ Spring Boot + 🔑 JWT

Would appreciate any practical recommendations, security standards, or real-world experience with this type of security finding. 🙏

---

💬 Final Question

How would you design the authentication and authorization architecture so that a captured, expired, revoked, or previously terminated token can never be reused to perform a protected operation — even when the attacker controls the browser and uses Burp Suite to manipulate the HTTP traffic?