Reject tokens with future signed_at timestamps #48
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR ensures that tokens with a
signed_attimestamp in the future are treated as invalid during decryption.Currently, if a token has a future
signed_at, it can remain valid longer than the configuredmax_age. This undermines the expiration logic thatmax_ageis meant to enforce.Here’s an example:
While
:infinityis an option for long-lived tokens, whenmax_ageis to seconds value, developers expect it to be enforced consistently. This change brings the implementation in line with that expectation.I just set this to return
{:error, :invalid}, but I am curious your thoughts on improvements to the API, as this would be be a breaking change. However,{:error, :expired}does not seem to really communicate to the caller what is truly the issue. As a consumer, I'd like to be able to see these tokens in my logs so I can detect when this happens.Thank you!