If you can share a link to your codebase, if it’s open-source, that would be helpful. The JWT in your example of a failing request decodes as follows:
"{\"id\":4,\"exp\":1681219�43}"
whereas the JWT in your example of a successful local request decodes as follows:
{"id": 2, "exp": 1681203148}
There’s a difference here in the decoded results: In the former, the JSON has been double encoded, which is likely to cause the unexpected behavior you’ve observed with failing authentication. The token you’re sending to the API is invalid.
I am not sure why this would happen when deployed vs. when running locally, as I would typically expect double encoding like this to be caused by an error in the code – e.g: '{"x": "y"}'.to_json
– so it would consistently fail across environments.
So, you need to track down why the input is double encoded when the application is deployed vs. when it’s running locally. A good starting point would be to consider whether you’re actually running the production build locally: when you run Fly deploy, Fly will build a container, and it is that container that Fly is running, not your Ruby on Rails application. If you haven’t tested the container locally, do that first: let Fly do a build, then do something like:
fly image show
Then from the result, extract the image in the format registry.fly.io/repository:tag
. So, using the following example:
Image Details
Registry = registry.fly.io
Repository = example
Tag = deployment-01GRMJ0NCKBPTVZPZ8QKSXT4DD
Version = N/A
Digest = sha256:146f5737def0242785cc2a2b1703ebb28e3486bd0e70e619d634d122aec6388b
The image would be:
registry.fly.io/example:deployment-01GRMJ0NCKBPTVZPZ8QKSXT4DD
Next, copy all of your Environment Variables from fly.toml
into a file called fly.env
and then run the image like so (where 8080
is a best guess at the port you’re using – swap it out if neccessary):
docker run -p 8080:8080 --env-file fly.env registry.fly.io/example:deployment-01GRMJ0NCKBPTVZPZ8QKSXT4DD
Now do your tests again, and see if you see the same behavior that you’re seeing on the Fly deployment. If you are able to reproduce it, you know there’s an issue with how your application is behaving when containerised.
Also, you can decode a JWT yourself using jwt.io. A great first step when debugging authentication issues is verifying that your JWT is exactly as you expect, because the encoded nature of a JWT can easily obscure simple issues that you’d catch easily otherwise 
(Also, just for future reference, when you share screenshots when asking for programming/software/infrastructure help, you should include a text version, because often the specifics of the error message are very important for people to copy and paste. I had to retype both JWTs out by hand in order to decode them!)