Only some registered claims can be optionally required

[Walker]

👋 I noticed that only a subset of the registered claims can be configured to be required.

PR #351, for example, adds the requireExp field to the core Validator.

Other fields like iat are hard-coded to not be required.

jwt/validator.go

Lines 117 to 119 in 6bcdd9d

 if err = v.verifyIssuedAt(claims, now, false); err != nil { 
 	errs = append(errs, err) 
 } 

We also have a 'expected' claims like expectedIss which are hard-coded to be required.

jwt/validator.go

Lines 130 to 134 in 6bcdd9d

 if v.expectedIss != "" { 
 	if err = v.verifyIssuer(claims, v.expectedIss, true); err != nil { 
 		errs = append(errs, err) 
 	} 
 } 

Semantically, I find the line between "expected" and "required" to be extremely thin. I propose moving to a system like expiratedAt where no required field is hard-coded and all can be configured with ParserOptions

jwt/validator.go

Lines 102 to 107 in 6bcdd9d

 // We always need to check the expiration time, but usage of the claim 
 // itself is OPTIONAL by default. requireExp overrides this behavior 
 // and makes the exp claim mandatory. 
 if err = v.verifyExpiresAt(claims, now, v.requireExp); err != nil { 
 	errs = append(errs, err) 
 } 

This change would standardize on a two boolean system for each registered claims:

• WithFoo which determines which claims should be verified if provided. For example, see WithIssuedAt and WithIssuedAt
• WithFooRequired which determines which claims should be required. For example, see WithExpirationRequired

The existing API (from what I can see) will remain the same. This change would only add ParserOption funcs to fill in the missing gaps.

I'd be happy to work on a PR. Is this a welcome change? Does anyone have any feedback?

[Christian Banse]

That's a good point. To be honest, we didn't pay too much intention on the internal naming of "required" vs "expected". As long as the existing API will stay the same, I am open to fill the gaps with some parser options, provided this will not "explode" in the sense that there are now dozens of these functions, we somehow need to maintain and make sure that we "never" change them (at least in this major version).

For me, what would be important is that the STANDARD behaviour, i.e., without any options is exactly as specified in the RFC. Any additional expectations and requirements are up to the user, but we should not diverge from the standard.

TL;DR: Yes. Please go ahead, but be mindful in the changes introduced and expect that it will take some time until we finally decide to merge such a PR.