aidantwoods / go-paseto

Platform-Agnostic Security Tokens implementation in Golang.
https://pkg.go.dev/aidanwoods.dev/go-paseto
MIT License
282 stars 16 forks source link

`errorBadSignature` is not exported #38

Closed minus7 closed 1 year ago

minus7 commented 1 year ago

errorBadSignature and similar errors are not exported, so there's no way besides comparing strings to tell what the problem with a token is for a consumer of the API.

aidantwoods commented 1 year ago

You should be able to detect if something is either a rule error or a token error (things like badly formatted tokens or cryptographic failure). See the release notes here (which I'll remember to document elsewhere because I'm realising I didn't put any information about it in the README): https://github.com/aidantwoods/go-paseto/releases/tag/v1.2.0

aidantwoods commented 1 year ago

As far as the underlying specific reason for an error goes (like a bad signature), this isn't part of the public API and so isn't exported. Tokens which error due to a bad signature might fail due to being poorly formatted first, and the exact reason an invalid token fails might change in future for the same invalid token.

You can, of course, inspect the error string, but be aware that this is highly subject to change and considered an implementation detail 🙂

minus7 commented 1 year ago

The rationale: I want to try decoding a token against multiple keys. But I guess just trying the next key on any kind of error and failing with the error of the last one works as well as only trying the next key on a signature error.

aidantwoods commented 1 year ago

You might want to use the token footer to specify a key ID (so you know which key produced the token), that way you only need to attempt to do the crypto once.

If you extract the token footer prior to verification it won't be verified at that point, but if the token passes verification using the key then that includes integrity checking the footer.

minus7 commented 1 year ago

That's actually already done on the signing side, I just forgot about it when repurposing old code (from when PASERK wasn't a thing yet). Thanks for your constructive replies.

To sum up the answer to the original question: You don't want to expose more specific decoding failure reasons beyond TokenError and RuleError. It usually isn't necessary to know anyway (as seen here).