Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pattern matching on subject validation #250

Closed
wants to merge 13 commits into from
Closed

Pattern matching on subject validation #250

wants to merge 13 commits into from

Conversation

oxisto
Copy link
Collaborator

@oxisto oxisto commented Oct 26, 2022

Pattern matching on subject

oxisto and others added 13 commits August 27, 2022 11:40
This commit serves as the basis for further `v5` developments. It will introduce some API-breaking changes, especially to the way tokens are validated. This will allow us to provide some long-wanted features with regards to the validation API. We are aiming to do this as smoothly as possible, however, with any major version. please expect that you might need to adapt your code.

The actual development will be done in the course of the next week, if time permits. It will be done in seperate PRs that will use this PR as a base. Afterwards, we will probably merge this and release an initial 5.0.0-alpha1 or similar.
This PR removes the old legacy standard claims, which have been deprecated since the beginning of the `v4` module in favor of the newer `RegisteredClaims`. Removing them before any further changes to the validation API is quite useful, as less code needs to be adapated.
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
  * Not verifying `iat`, since this is actually just an informational claim. When purely looking at the standard, this should probably the default
  * 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, rather than just a `Valid` function. This is also more semantically correct.
* 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.
Co-authored-by: Micah Parks <66095735+MicahParks@users.noreply.github.com>
@oxisto oxisto changed the base branch from main to new-validation-api October 26, 2022 20:16
@oxisto oxisto changed the title pattern matching Pattern matching on subject validation Oct 26, 2022
@oxisto oxisto added enhancement New feature or request next The next iteration of development, currently `v6` labels Oct 26, 2022
Base automatically changed from new-validation-api to v5 December 5, 2022 13:56
@oxisto oxisto closed this Feb 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request next The next iteration of development, currently `v6`
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant