| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This library has been running in a production codebase for a while and
can be considered stable.
There is a minor breaking change between this version and the previous
0.1.0 in that the `ValidationError` enum has gained additional variants.
|
|
After upgrading the base64 library, tests were failing because the new
default of the library is to disallow trailing bits in JWTs.
Some JWT provider implementations do however use this "forgiving"
version of base64-encoding, hence it is required for token validation.
This adds a base64::Config with the appropriate settings and also
chains base64-errors separately from other token errors.
|
|
|
|
|
|
|
|
|
|
Thanks to @bvs for pointing this out.
|
|
|
|
|
|
Implements initial validations of token claims. The included
validations are:
* validation of token issuer
* validation of token audience
* validation that a subject is set
* validation that a token is not expired
|
|
These fields are only used to constrain deserialisation to the
supported values, but have no further effect.
`rustc` throws warnings about them not being used, which this commit
disables.
|
|
|
|
|
|
Implements the logic for validating a token signature and returning
its decoded headers and claims.
This does not yet apply claim validations, as those have not been
specified yet.
|
|
Introduces a new struct type which contains the token's headers and
claims as JSON values. This is constructed by validating a token and
allows library users to deal with the deserialised values as they
please.
|
|
There are multiple points in the code where a token part needs to be
deserialised (i.e. first base64-decoded, then JSON-deserialised). This
is extracted to a helper function in this commit.
|
|
|
|
|
|
Introduces the internal function for validating JWT signatures. The
process is relatively straightforward:
1. Create an OpenSSL signature verifier using the public key from the
JWK.
2. Split the JWT into the data (header + claims) and signature parts.
3. Validate the data against the signature using the verifier from (1)
OpenSSL "cleanly" returns a boolean in case of an invalid signature,
but an otherwise successful operation.
This is represented differently in the returned error variant, with an
invalid signature being represented as `InvalidSignature`, and other
errors as the `OpenSSL` error variant which wraps the underlying
OpenSSL issue.
Successful validation returns an empty `Ok` result.
|
|
|
|
This makes the library slightly more "rusty". Instead of returning a
validation result which also represents potential success, use an enum
representing the error variants and the standard library's
`Result`-type to represent success/failure.
|
|
|
|
|
|
|
