This PR aims at implementing compliance to RFC7519, as documented in #11 without breaking the public API. It creates a new struct RegisteredClaims and deprecates (but not removes) the StandardClaims. It introduces a new type NumericDate, which represents a JSON numeric date value as specified in the RFC. This allows us to handle float as well as int-based time fields in aud, exp and nbf. Additionally, it introduces the type StringArray, which is basically a wrapper around []string to deal with the oddities of the JWT aud field.

Closes #11

Unfortunately the Go module proxy (i.e., mirror) cached 2 versions:

https://pkg.go.dev/github.com/golang-jwt/jwt?tab=versions

When a user does a go get github.com/golang-jwt/jwt it will download the following version:

github.com/golang-jwt/jwt v3.2.0+incompatible // indirect

Whereas it should import the correct one (based on latest commit on main)

github.com/golang-jwt/jwt v0.0.0-20210529012641-6a07921e6808 // indirect

If we cannot get those 2 versions removed from the proxy, we'll have to go with plan B... add a /v3 and tag a v3.2.1

See https://github.com/dgrijalva/jwt-go/issues/462 for a lengthier discussion and background.

For brevity, there is/was an attempt to migrate to the gors organization, issues here, but unfortunately there was no response on GitHub issue or Slack #gofrs channel.

Hopefully other can chip in, but afaics the goal of this org/repo:

1. patch any outstanding security issues
2. add module support
3. maintain the existing jwt-go API in its current form
4. setup GitHub Actions as CI for existing tests
5. have a few independent maintainers to spread the load and trust of maintenance with the ultimate goal of the Go community having access to a stable JWT package.

The intention is to support the package in its current form without any major re-write or refactor.

I still hope one day the Go standard library or /x will add JWT support and backing from the Go team.

If there is agreement we can setup independent GitHub issues to tackle the above and address these in particular.

https://github.com/dgrijalva/jwt-go/issues/428 https://github.com/dgrijalva/jwt-go/issues/463

cc @ripienaar @Waterdrips @lggomez

Some guidelines in designing the new validation API

• Previously, the Valid method was placed on the claim, which was always not entirely semantically correct, since the validity is concerning the token, not the claims. Although the validity of the token is based on the processing of the claims (such as exp). Therefore, the function Valid was removed from the Claims interface and the single canonical way to retrieve the validity of the token is to retrieve the Valid property of the Token struct.
• The previous fact was enhanced by the fact that most claims implementations had additional exported VerifyXXX functions, which are now removed
• All validation errors should be comparable with errors.Is to determine, why a particular validation has failed
• Developers want to adjust validation options. Popular options include:
  • Leeway when processing exp, nbf, iat (#98, #237)
  • Setting the time manually, especially for testing (#188)
  • Not verifying iat, since this is actually just an informational claim. When purely looking at the standard, this should probably the default (#175)
  • Verifying aud by default, which actually the standard sort of demands. We need to see how strong we want to enforce this
• Developers want to create their own claim types, mostly by embedding one of the existing types such as RegisteredClaims.
  • Sometimes there is the need to further tweak the validation of a token by checking the value of a custom claim. Previously, this was possibly by overriding Valid. However, this was error-prone, e.g., if the original Valid was not called. Therefore, we should provide an easy way for additional checks, without by-passing the necessary validations

This leads to the following two major changes:

• The Claims interface now represents a set of functions that return the mandatory claims represented in a token, such as exp, and so on, rather than just a Valid function. This is also more semantically correct and makes our codebase smaller and way more maintainable.
• All validation tasks are offloaded to a new (optional) Validator, which can also be configured with appropriate options. If no custom validator was supplied, a default one is used.

Some smaller goodies:

• This introduces a new convenience feature for map claims: ParseXXX (naming to change) functions, that make it easy to parse a key as a certain JWT special type such as numeric date.

Remaining tasks

• [x] Provide a way for custom claims for additional verification
• [x] Update examples with validator goodness
• [x] Add option to skip iat
• [x] Moving the TimeFunc to the validator instead of a global function
• [x] Make aud verification default-ish, at least if a new validator is provided

My JWT has a header like this:

{
  "typ": "JWS",
  "alg": "RS256",
  "kid": "9167337"
}

Note this is is JWS not JWT.

When I call jwt.Parse() on it like this, I get token.Valid is false:

token, err := jwt.Parse(authToken, func(token *jwt.Token) (interface{}, error) {
        return []byte("AllYourBase"), nil
})

The error is "key is of invalid type". Am I doing something wrong here, or is JWS unsupported?

https://github.com/golang-jwt/jwt/blob/4bbdd8ac624fc7a9ef7aec841c43d99b5fe65a29/ecdsa.go#L135-L136

from #33, means that golang-jwt/jwt now requires go1.15.

Is this intentional?

Introduces modules support with with/v4 SIV

• [x] Update migration guide
• [x] Update README to ensure import paths are correct referenced

fixes #5 #3 #30

Issue #67

Add support of JWE with one key (Compact)

Add AES GCM cipher to encrypt content Add RSA-OAEP to encrypt key

Add test from RFC7516 Section 3.3

cc @mfridman

After upgrading from 4.3.0 to 4.4.0, my custom implementation of the Claims interface is broken:

	*Claims does not implement jwt.Claims (wrong type for Valid method)
		have Valid() error
		want Valid(opts ...jwt.validationOption) error

This is a small revert to the optimizations made to the encoding/decoding in https://github.com/golang-jwt/jwt/pull/33.

While technically JWTs should not have padded characters in Base64 URL encoding, it seems like not every provider may follow this construct, specifically AWS Cognito as seen in https://github.com/golang-jwt/jwt/issues/92.

While the change initially was made to have better optimization, it has left compatibility issues, forcing dependencies to stay on v3.2.1 until an update occurs. Thus the proposal is to simply undo the changes made in that section of code, and create a new ticket to better optimize this section.

This forwards the changes of https://github.com/form3tech-oss/jwt-go/pull/14 to the upstream repository.

I am not the author of the original PR (nor do I know much about JWT), but thought I'd give this an attempt, following the discussion in https://github.com/Azure/go-autorest/issues/642 (and issues linked from there).

Fixes a security vulnerability where a jwt token could potentially be validated having invalid string characters.

(cherry picked from commit a211650c6ae1cff6d7347d3e24070d65dcfb1122) https://github.com/form3tech-oss/jwt-go/pull/14

Hi, After spending a few hours on trying to import Apple Mapkit p8 file, which is pkcs8, i have stumbled on someones post here: https://github.com/dgrijalva/jwt-go/issues/179

It includes a working function to import the private key, i've tested it and it works. While i am not the author of the post in the link, i feel it would be beneficial to many people to have this function be included in your repo. Would you be interested in a pull request with the above mentioned change ? I will make sure to include the original author.

Found the vulnerability with CVE code PRISMA-2022-0270 in version v4.4.2. Can we get this fixed?

Vulnerability description: github.com/golang-jwt/jwt/v4 module from all versions is vulnerable to Denial of Service (DoS) due to token without ExpiresAt can cause panic.

I faced an precision issue when calling UnmarshalJSON for NumericDate.
For example, when original unix time was 9223371974719179007,
NumericDate.Unix() shows 9223371974719178752 after json.Unmarshal.

	var t jwt.NumericDate
	json.Unmarshal([]byte("9223371974719179007"), &t)
	fmt.Println(t.Unix()) // 9223371974719178752

I think that this issue is caused because code uses float64.

https://github.com/golang-jwt/jwt/blob/0c4e3879854669acd15ea435f2c8aada6c73810a/types.go#L88-L93

This patch use rational type of math/big standard package when parcing JSON to improve precision.

This patch includes test by 10bc0152ec873c8c510a6c6db7c14a0470a6c43e .
We can check that added test is going to be failed by checkout 10bc0152ec873c8c510a6c6db7c14a0470a6c43e .