Make payload available when verifying an expired token

[staplespeter]

Currently when verifying an expired token the JWTExpired exception is thrown. This makes it impossible to access the returned payload. Please either attach the payload to the exception, or do not throw and flag the expiry in the returned object.

[panva]

Unless the JWT is a JWE you can of course decode it after you've caught the exception...

but there is no guarantee that the claims should be trusted, the order of operations is not given.

[staplespeter]

Thanks, I had not read that part of the documentation. However, this will not verify the signature, so separate and subsequent decoding without successful verification undermines the integrity of the token, and thus is not safe.

…

On Wed, 7 Sept 2022, 19:02 Filip Skokan, ***@***.***> wrote: Unless the JWT is a JWE you can of course decode it after you've caught the exception... — Reply to this email directly, view it on GitHub <#447 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGJV4S3IG4KCIKBAQG2HRQTV5DKDVANCNFSM6AAAAAAQG6OGP4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[panva]

Returning claims with an error would be then exactly the same since there is no guarantee that verify functions check (and will always check) signatures before checking the claim set

[staplespeter]

I don't think that is the case. In order for the "exp" to be trusted and used to check if the token has expired the signature must be valid

…

On Wed, 7 Sept 2022, 19:47 Filip Skokan, ***@***.***> wrote: Returning claims with an error would be then exactly the same since there is no guarantee that verify functions check (and will always check) signatures before checking the claim set — Reply to this email directly, view it on GitHub <#447 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGJV4SZD2RZKVWNJQYMUUZTV5DPNVANCNFSM6AAAAAAQG6OGP4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[staplespeter]

Apologies, I've answered my own question. Was in the middle of a game of Bananagrams writing the last reply and was a bit distracted. If the JWTExpired exception is thrown then the signature must be valid in order to perform that check. You were correct. Thanks again for the tip

…

On Wed, 7 Sept 2022, 21:17 Peter Staples, ***@***.***> wrote: I don't think that is the case. In order for the "exp" to be trusted and used to check if the token has expired the signature must be valid On Wed, 7 Sept 2022, 19:47 Filip Skokan, ***@***.***> wrote: > Returning claims with an error would be then exactly the same since there > is no guarantee that verify functions check (and will always check) > signatures before checking the claim set > > — > Reply to this email directly, view it on GitHub > <#447 (reply in thread)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AGJV4SZD2RZKVWNJQYMUUZTV5DPNVANCNFSM6AAAAAAQG6OGP4> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[staplespeter]

Apologies, I didn't realise you were the author as I received a different name on email messages. It doesn't make sense to me not to verify the signature first, hence my assumptions, and not understanding your answer as the reality of how the library works.

Is there any reason why you cannot guarantee the signature is verified before a claims error?

A consuming application may take an incorrect path based on a claims error when it should have acted on an invalid signature, as the claim error itself cannot even be guaranteed to be valid. And the application cannot detect spoofing attempts unless all the standard claims are correct.

Should the application never use the data from an expired token, even if it should be valid?

[panva]

Should the application never use the data from an expired token, even if it should be valid?

Not unless I would commit to the code always verifying signatures first. This is not a guarantee currently described in the documentation. AS-IS it is just what the code happens to do at the moment.

[panva]

FWIW I've added a test for that behaviour in ec6a6a5

[staplespeter]

Okay, thanks for the consideration of, what I feel, is an issue.