Previously, when parsing claim values, we used `json.UnsupportedTypeError` to denote if a claim string value is not of the correct type. However, this could lead to panics if a nil value is present and the `Error` function of the `json.UnsupportedTypeError` is called, which does not check for nil types.
Instead, we just now use `ErrInvalidType` similar to the map claims.
Fixes#315
* Updated MIGRATION_GUIDE.md after changes to Token and Parser
* Updated doc
* Cleanup of README and refer to project page
* Update MIGRATION_GUIDE.md
Co-authored-by: Michael Fridman <mf192@icloud.com>
* Wrapping markdown files at 80
---------
Co-authored-by: Michael Fridman <mf192@icloud.com>
* add documentation around Verify & Sign to detail why string is not an advisable input for key
* Refer to the usage guide
---------
Co-authored-by: Dillon Streator <dillonstreator@Dillons-2nd-MacBook-Pro.local>
Co-authored-by: Christian Banse <oxisto@aybaze.com>
* 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
By default base64 decoder works in non-strict mode which
allows tweaking signatures having padding without failing validation.
This creates a potential problem if application treats token value as an identifier.
For example ES256 signature has length of 64 bytes and two padding symbols (stripped by default).
Therefore its base64-encoded value can only end with A, Q, g and w.
In non-strict mode last symbol could be tweaked resulting in 16 distinct
token values having the same signature and passing validation.
This change adds backward-compatible global config variable DecodeStrict
(similar to existing DecodePaddingAllowed) that enables strict base64 decoder mode.
See also https://github.com/golang/go/issues/15656.
Signed-off-by: Alexander Yastrebov <yastrebov.alex@gmail.com>
* Implement a BearerExtractor
This is a rather common extractor; it extracts the JWT from the HTTP
Authorization header, expecting it to include the "Bearer " prefix.
This patterns is rather common and this snippet is repeated in enough
applications that it's probably best to just include it upstream and
allow reusing it.
* Ignore case-sensitivity for "Bearer"
Michael Fridman