JWT token that doesn't supply expiration is assumed as valid

[jonathanwiesel]

When a token response does not supply the current detected attributes for token expiration (expires_in_sec, expires_in, expires) the token is assumed to be valid.

[sqrrrl]

Need more information for this to be actionable. Can you provide a sample of where you think this is an issue?

AFAICT non-expiring JWTs are allowed (although strongly discouraged) and it's not clear what, if any, changes should be made to the library.

[jonathanwiesel]

Sure thing, the hasAccessmethod is checking the isExpired method, which checks for specific attributes (expires_in_sec, expires_in, expires) to determine expiration, in case there's no expiration supplied (rare but could happen) or the expiration attribute name is different than the currently configured ones (for example exp) the method returns false, therefore considering it not expired.

Would be great that in case a different expiration attribute is supplied by a system it could be at least supplied as configuration