For an implementation, see this repository.
A recurring question is how to increase the expiration time of signed URLs so that they can be used more like permanent URLs rather than short-lived ones. For example, when a user buys an ebook from a site, you might want to send an email with a link pointing to the book. In this case, the expected behavior when the link is clicked is to open the book, even if the user is not logged in on your site. It's no wonder why signed URLs are among the first ones that come to mind to implement this solution as they do this exactly: a URL that is equivalent to the file it was signed for. And the allure is, of course, simplicity as it would not require any specific infrastructure on your end. Just a URL signed, and that's all.
But a long-lived signed URL brings a lot of problems and not just the issue of increasing the expiration time.
A good but not equivalent solution is to make a stable link inside your backend that checks the user to make sure he has access to the content, then redirect to the file. In this case, you don't need long-lived signed URLs as there is an access check to make sure only people who bought the book has access to it.
But what if the user is not logged in? In this case, he will be redirected to the log-in page. It's not exactly the same as clicking the link in the email and the book opens even without having previously logged in.
A good illustration to the difference between these two cases is Google Drive's sharing options. You can choose to restrict a given item to collaborators, in this case if someone opens it he needs to sign in first. Then access is checked and will see the item only if he has been given access.
But you can choose to allow opening with only the link. In this case, anyone even without a Google account can open the item.