I think this is important to raise and repeat for everyone for awareness as much as possible, but it is also overrating this issue once it is known. I posted some simple code here that I think handles this and it should not be complicated to fix, as per the guidelines at the “best practices” link. I am grateful you pointed it out to me, but it should not be difficult to manage or affect the usage.
It is not really the same thing and then you are going down proprietary cloud software pathway (like AWS services) vs. having a generic and portable solution. A signed URL can typically be shared and used by anyone (easy for average person to do). While if you have a simple script just checking the JWT in the request, this is not easily shareable. You also don’t have to make a new signed link or token for every single access attempt with the JWT.
And you could copy and paste your entire system over to another service (including just your own raw server) and it will still work.
For example it would take a few hours at most to set up an Elixir server with a Router that checks the header for the token and either returns the file or not based on parameters set in the token. This is very portable and simple design. You can search “how to make elixir check token in request before allowing access to file at url on server” on ChatGPT and it lays it out pretty simply.
I hate using proprietary systems like AWS more than is absolutely necessary.
Doing the equivalent with signed links (even on Elixir) is less secure again as the links can be more easily shared and more work. You would still need to supply some identifying information for the accessing user to the server for it to determine if that user is allowed to receive a signed link. Or server-server communication to determine this. This doesn’t fix that. And it is a pain in the ass on proprietary services like AWS which I touch as little as possible. And more computational work overall.
I don’t think signed links are as good a solution in general. I don’t see any particular advantage to them. They just seem messier and even more work to me.
If I give a user a JWT periodically to access a “low security” resource documents repository, that server can quickly verify their identity, authorization level, and either allow or deny based on the file requested and those details with a simple script. And this is so easy.
I can’t think of any reason for signed URLs at all unless perhaps it is a situation where they are intended to be spammed out to many people at once for some reason (like a time limited giveaway email link or something) or to track URL clicks again in things like emails.
I agree in theory (though more security is always better - try guessing a session ID AND cracking JWT RS256 encryption AND guessing other verification details of the session like the exact date created 
) and that is why I think the decision about the token or not or encryption is based on the potential ancillary benefits and any net harm. Ie. There is no net harm to using the JWT in this case as long as you watch the “alg” and “kid” and it provides extra benefits (if you want them) like what I said for a method of easy self-contained non-proprietary verification of user resource access in disconnected systems.
In terms of the format of tokens, thanks for pointing out PASETO, but there is also an advantage to sticking with what is popular and conventional. There is good interoperability, eg. with OpenAuth on JWT. There is only so much time in the day and using one token type everywhere and knowing it well is better than mixing and matching and adding too much complexity.
