--- title: "Fixing 403 auth errors when you replay traffic | Speedscale" description: "Replay an authenticated flow and the protected calls fail with 403. Here is how proxymock recommendations fix the expired bearer token in one click." canonical: "https://speedscale.com/blog/fix-403-auth-errors-traffic-replay-proxymock/" --- ![Stalled requests blocked by a glowing 403 badge on the left, then flowing through a key icon and continuing as clean data streams on the right](https://speedscale.com/_astro/featured-image.BSC12VZK_Z1xCHq0.webp) # Fixing 403 auth errors when you replay traffic Jun 12, 2026 [By Ken Ahrens](https://speedscale.com/blog/author/ken-ahrens/) [API testing](https://speedscale.com/blog/category/api-testing/) [Developer tools](https://speedscale.com/blog/category/developer-tools/) [Security](https://speedscale.com/blog/category/security/) [Traffic Replay](https://speedscale.com/blog/category/traffic-replay/) * * * Trigger warning: this one is about Java, authentication, and Docker Compose files. If that is not your thing, I am sorry, but they are part of life and they are honestly not that hard to work with. Everything here is open source on our [GitHub repo](https://github.com/speedscale/demo/tree/master/java-auth), so you can follow along. _Recording an authenticated Java flow, replaying it, hitting the dreaded 403, and fixing it with a proxymock recommendation._ ## A little demo app that logs in and calls some APIs The demo is a Spring Boot service that hands out JWT bearer tokens. A test script logs in once and then makes a few authenticated calls with the token it got back: ``` ./scripts/test.sh localhost:8081 ``` It logs in, grabs the `accessToken`, and calls `GET /api/auth/user` three times with `Authorization: Bearer `. No sweat. That works. What I actually want is more visibility into what these calls do, and a way to turn them into repeatable tests. ## Recording the traffic with proxymock [proxymock](https://proxymock.io/) is a free tool that records the traffic going in and out of your app. You run the recorder, tell it the port your app listens on, and point your client at proxymock’s port (`4143`) instead: ``` proxymock record --app-port 8081 -- docker compose up ``` Run the same test script through port `4143`, and now I have a recording. proxymock writes one Markdown file per request. If you use AI coding tools, they like reading those directly. If you want to read them as a human, there is a web interface: ``` proxymock web ``` I can see the login call and the three user calls, each with its request, response, and headers. ## Replaying it, and the dreaded 403 What I really want is to replay this traffic so I have some test automation around the code. So I run it back against my local app: ``` proxymock replay --in ./proxymock --test-against localhost:8081 ``` Except this did not work right. The first call worked, but the rest did not. We got the dreaded `403`. If you have ever tried to diagnose one of these, you know the pain. You look in the response and there is nothing there. You look in the headers and they do not tell you what is going on. The information is here, you are just not allowed to see that data. And the reason is we are replaying with the old token. The recording captured the bearer token that was minted at record time, that token has since expired, and the replay is faithfully resending it on every call after the login. ## Reviewing the recommendations So to fix that, you come into the **Recommendations** panel. proxymock already analyzed the replay, and there is a recommendation that identifies the OAuth handshake. It found the access token and highlighted it. Accept that one. There are other recommendations too. proxymock noticed an email address in the traffic, for instance. I happen to like that email and want it to pass through unchanged, so I leave that recommendation alone. Now run the replay one more time: ``` proxymock replay --in ./proxymock --test-against localhost:8081 ``` This time the console says `Applied 1 active blueprint(s) to replay`, and I get a 100% match rate. Everything works, because the recommendation made sure the token the app issues on the first call is the token used on all the rest. ## What the recommendation actually did If you are curious, proxymock saved the fix as a **blueprint** you can open and inspect. Here is the chain it built: ``` (networkaddr CONTAINS "localhost" AND location IS "/api/auth/session/login" AND command IS "POST") | res_body() | json_path(path=accessToken) | smart_replace_recorded(overwrite=true) ``` It goes into the response body of the login endpoint, uses a JSON path to grab the `accessToken`, and runs a smart replace. Because the smart replace matches on the token value, it rewrites the `Authorization` header on every protected request without me naming each one. There is a whole library of these transforms if you want to do more, but the recommendations are a quick and dirty way to get up and running. This is the same token correlation our cloud product does, running locally on your laptop. ## Try it yourself The full walkthrough lives in the [proxymock docs](https://docs.speedscale.com/proxymock/guides/recommendations/), and the demo app is [on GitHub](https://github.com/speedscale/demo/tree/master/java-auth). There is a lot more you can do with the recorded data. If you have questions, reach out at [proxymock.io](https://proxymock.io/). ## Table of Contents ## Stop writing API mocks by hand proxymock records real traffic from your running app and replays it as mocks — HTTP, gRPC, Postgres, Kafka, and more. Install in 30 seconds, no account required. [Install proxymock](https://docs.speedscale.com/proxymock/getting-started/installation/) [View the docs](https://docs.speedscale.com/proxymock/)