Fix Expiry.Time() to return zero-value of time.Time{} when n is 0

[dtuck9]

time.Unix(0, 0) does not return time.Time{} as one might expect. Admittedly, this is a work around for what I'd perceive as a bug in golang.

For reference, this is required for validating JWT expiration only where the expiry is set. E.g.:

if !claims.Expiry.Time().IsZero() && claims.Expiry.Time().Before(time.Now()) {
     return errors.New("Expired token")
}

Please let me know if there's a more preferable way to accomplish this check.

See https://play.golang.org/p/sM4SZKzWvFw

[CLAassistant]

All committers have signed the CLA.

[csstaub]

This is a nice catch, thank you @dtuck9. One thing I'm worried about here is the potential confusion between the value not being set in the claims (exp, iat and nbf are all optional) and the value being set explicitly to 0 in the JSON. It's unlikely someone would want to have a JWT that expires at UNIX epoch 0 of course, but I wouldn't want the code to get confused about it either way. So possibly a better fix is to make the NumericDate a *int64 (or make the fields *NumericDate) and update the marshal/unmarshal logic. I think I'll have to ponder this a bit over the weekend.

[csstaub]

Though I suppose if we change NumericDate to be an *int64 anyone not currently using NewNumericDate to construct NumericDate values will have their code broken. But on the other hand, it's also silly that exp:null and exp:0 deserialize to the same representation. Maybe we can just throw an error if we encounter exp:0 (or more generally, exp < 1) and just make those values unparseable.

[csstaub]

I added some changes on top of your branch in https://github.com/square/go-jose/compare/v2...cs/fix-expiry-zero-time?expand=1, please take a look and let me know what you think.

[dtuck9]

@csstaub That looks like a pretty good compromise, and seems to be in line with common practice (and certainly solves the problem I was trying to solve where an unset exp came through as the zero-value).

Would you like me to close this PR in favor of your add-ons?

[csstaub]

I’ll merge my branch directly and then it should close this out as merged automatically, I think.