* Exported `NewValidator`
Previously, we had `newValidator` as a private function. This PR exports this function so that validation can be done independently of parsing the claim.
* Moving `DecodeSegement` to `Parser`
This would allow us to remove some global variables and move them to parser options as well as potentially introduce interfaces for json and b64 encoding/decoding to replace the std lib, if someone wanted to do that for performance reasons.
We keep the functions exported because of explicit user demand.
* Sign/Verify does take the decoded form now
* improve code comments, including security consideration
* Add link to URL with details about security vulnerabilities.
* Update token.go
Co-authored-by: Christian Banse <oxisto@aybaze.com>
* Update token.go
Co-authored-by: Christian Banse <oxisto@aybaze.com>
* update code comments
Co-authored-by: Christian Banse <oxisto@aybaze.com>
Previously, returning a `jwt.ValidationError` from `jwt.Parse()` or
`jwt.ParseWithClaims()` would result values the error to be
ignored.
For example, when testing the signature while parsing the token, it
was not possible to return `jwt.ValidationErrorSignatureInvalid`.
The documentation shows an example for returning an `errors.Error`,
but this is not enough.
We change the `jwt.ParseWithClaims()`-function and check whether the
returned error from the `KeyFunc` is already a
`jwt.ValidationError`-type and return as-is.
This allows us to do the following:
token, err := jwt.ParseWithClaims(authToken, claims, func(token
*jwt.Token) (interface{}, error) {
if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
vErr := new(jwt.ValidationError)
vErr.Errors = jwt.ValidationErrorSignatureInvalid
vErr.Inner = fmt.Errorf("invalid signature")
return nil, vErr
}
return []byte(MySecret), nil
})
The idea is to then be able to check the `Errors`-member:
} else if ve.Errors&jwt.ValidationErrorSignatureInvalid != 0 {
return fmt.Errorf("Authentication Token has invalid signature")
}
This is not something users of this library would commonly use but I'm
hitting a case where I still want to transmit the values contained
inside of the token trough the system, after it's been verified by the
frontend.
In that case it would be easier just to transmit the token around and be
able to parse the values within, without having to verify the signature.
The backend services also don't have access to the user secrets to
validate the signature.
if parser.UseJSONNumber is true then the Claims[“exp”] and
Claims[“nbf”] can be full int64 range, not limited to float64
vnbf and vexp are just flags for whether or not the values were
obtained through either method and should be checked
bt-nia