New validation API #236

oxisto · 2022-08-27T10:46:48Z

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 (Token used before issued #98, Expiration skew #237)
- Setting the time manually, especially for testing (TimeFunc being static prevents from using this package in a parallel test #188)
- Not verifying iat, since this is actually just an informational claim. When purely looking at the standard, this should probably the default (Make issued at (iat) claim validation optional #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

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

map_claims.go

oxisto · 2022-08-27T11:43:13Z

An initial version of this is now ready to review. I will add some more tests once we agree on a more or less stable API.

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.

MicahParks · 2022-09-26T13:44:05Z

I haven't review these changes thoroughly, but glancing at the PR description, I feel neutral or favorable about the suggested changes. I'd be happy to review this PR if requested, but that would have to be next week at the earliest due to my current obligations.

I'm interested in resolving this PR for two reasons:

I'm concerned leaving this PR unresolved will cause a fork to emerge. I found it unfavorable with github.com/dgrijalva/jwt-go how many forks emerged for valid use cases or bug fixes.
Merging any breaking changes into this repository forces me to make an update to github.com/MicahParks/keyfunc. See the draft PR here: Support for jwt v5 MicahParks/keyfunc#46.

oxisto · 2022-09-26T18:34:18Z

I haven't review these changes thoroughly, but glancing at the PR description, I feel neutral or favorable about the suggested changes. I'd be happy to review this PR if requested, but that would have to be next week at the earliest due to my current obligations.

I'm interested in resolving this PR for two reasons:

I'm concerned leaving this PR unresolved will cause a fork to emerge. I found it unfavorable with github.com/dgrijalva/jwt-go how many forks emerged for valid use cases or bug fixes.

Merging any breaking changes into this repository forces me to make an update to github.com/MicahParks/keyfunc. See the draft PR here: Experimental support for jwt v5 MicahParks/keyfunc#46.

Your feedback on this PR would be most welcome!

b4k3r · 2022-09-30T11:13:34Z

What is ETA for v5?

oxisto · 2022-09-30T11:39:39Z

What is ETA for v5?

There is no fixed ETA. It is kind of relying on the co-maintainers having some time to review this PR :)

oxisto · 2022-10-15T12:30:55Z

@MicahParks did you already have time to look at this a more closely?

MicahParks · 2022-10-15T12:33:58Z

@MicahParks did you already have time to look at this a more closely?

Not yet, sorry. But it's still on my list of things to do.

MicahParks · 2022-10-15T18:48:11Z

@oxisto Thank you for the reminder yesterday, I've reviewed the PR today and will be posting it shortly.

Apologies in advance for any comments of mine that suggest improper or inconsistent things for this code base. I haven't familiarized myself with its entirety. I'm mostly familiar with the code surrounding jwt.Keyfunc and what I've learned when reviewing this PR.

Also, it seems some comments were removed on a few exported assets such as ParseWithClaims. I don't think that's in this PR here, but it would be good to get those back in the code base before v5 is released.

claims.go

map_claims.go

map_claims_test.go

validator.go

parser.go

validator.go

sermojohn · 2022-10-26T13:21:43Z

Very nice work!

This PR enables parsing and validation of the token using different APIs, so a token can be parsed once and validated by different validators.

This is very useful for implementation of token validation profiles described in the JSON Web Token Best Current Practices RFC.

…functions

oxisto · 2022-10-26T19:09:12Z

Thanks for the initial bunch of reviews, @MicahParks, @sermojohn. I incorporated most / all of your feedback. In re-enabling the map claim tests I stumbled upon a design flaw of the first iteration, in which the GetXXX functions of the Claims interface would not return an error. However, this is necessary for the MapClaims struct in order to differentiate between a non-existing value and an erroneous value.

validator.go

oxisto · 2022-12-03T08:46:29Z

Anything to add @mfridman ? I would
Love to get a v5 version out for Christmas :)

validator.go

validator_option.go

validator.go

mfridman · 2022-12-04T03:27:34Z

claims.go

-
-// Claims must just have a Valid method that determines
-// if the token is invalid for any supported reason
+// Claims represent any form of a JWT Claims Set according to


Have you considered an alternate scenario where we remove this (and map claims) entirely?

It might be a bad idea, but just throwing this thought out .. the user still has to assert the claims.

I think a lot of people still use map claims, so I am not 100 % convinced tbh.

Ye that's fair. My thought was .. there are too many ways to pass "claims"

map claims (default)

RegisteredClaims (structured, arguably could be the default?)

Custom claims that either implement Claims or embed RegisteredClaims

If we remove Claims interface entirely, and take an any .. would that simply the overall API?

Probably a bad idea, figured I'd bring it up but I think you're probably right .. a lot of people use map claims.

I think it actually gets easier with the new interface, because you do not need to implement any validation on your claim, but rather you can use any kind of struct/map type that supplies the needed standard claim values, such as exp, iat, etc. I think that is a pretty straight forward way of modelling claims now.

mfridman

Great job, thanks for taking a pass at this and cleaning things up. 🎉

I'm on board with most of these changes. The only thing that's sticking out to me is the Validator being exposed to the user.

oxisto · 2022-12-04T19:03:26Z

Great job, thanks for taking a pass at this and cleaning things up. 🎉

I'm on board with most of these changes. The only thing that's sticking out to me is the Validator being exposed to the user.

I made another cleanup pass and this should be fairly straightforward now. All validation options are now parser options and this has the added benefit that they also work with the Parse and ParseWithClaims functions directly:

token, err := jwt.ParseWithClaims(tokenString, &MyCustomClaims{}, func(token *jwt.Token) (interface{}, error) {
		return []byte("AllYourBase"), nil
	}, jwt.WithLeeway(5*time.Second))

or as part of a new parser

parser := NewParser(jwt.WithLeeway(5*time.Second))

If necessary, it is still possible to create a new (standalone) validator with `NewValidator:

val := NewValidator(jwt.WithLeeway(5*time.Second))

This is fairly close to what @dgrijalva originally had in the "old" v4 validation API.

mfridman · 2022-12-04T23:55:03Z

Overall the new API looks good from my side. I like how we're frontloading the options in one place.

The only options I'd suggest removing are WithSubject, WithIssuer and WithAudience .. but I also see how they can be useful. So not a blocker.

Happy to give this a stamp and merge it into the /v5 branch. Then we can do another pass, does that seem reasonable?

oxisto · 2022-12-05T08:22:58Z

Overall the new API looks good from my side. I like how we're frontloading the options in one place.

The only options I'd suggest removing are WithSubject, WithIssuer and WithAudience .. but I also see how they can be useful. So not a blocker.

Happy to give this a stamp and merge it into the /v5 branch. Then we can do another pass, does that seem reasonable?

Yap, looks good. Waiting for your official approval to merge it into v5 ;)

mfridman

lgtm. Let's merge this into the v5 branch and then do another few passes of reviews.

Apologies took me so long to get to this.

* New Validation API 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 <[email protected]>

tschaub · 2023-04-04T23:44:39Z

The old claims.Valid() method made it convenient to validate at least the exp claim without verifying the signature. With the new API, is there an easy way to skip signature verification but use the other claim validation logic?

[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [github.com/golang-jwt/jwt/v4](https://togithub.com/golang-jwt/jwt) | require | major | `v4.5.0` -> `v5.0.0` | --- ### ⚠ Dependency Lookup Warnings ⚠ Warnings were logged while processing this repo. Please check the Dependency Dashboard for more information. --- ### Release Notes <details> <summary>golang-jwt/jwt (github.com/golang-jwt/jwt/v4)</summary> ### [`v5.0.0`](https://togithub.com/golang-jwt/jwt/releases/tag/v5.0.0) [Compare Source](https://togithub.com/golang-jwt/jwt/compare/v4.5.0...v5.0.0) ### 🚀 New Major Version `v5` 🚀 It's finally here, the release you have been waiting for! We don't take breaking changes lightly, but the changes outlined below were necessary to address some of the challenges of the previous API. A big thanks for [@mfridman](https://togithub.com/mfridman) for all the reviews, all contributors for their commits and of course [@dgrijalva](https://togithub.com/dgrijalva) for the original code. I hope we kept some of the spirit of your original `v4` branch alive in the approach we have taken here. \~[@oxisto](https://togithub.com/oxisto), on behalf of [@golang-jwt/maintainers](https://togithub.com/golang-jwt/maintainers) Version `v5` contains a major rework of core functionalities in the `jwt-go` library. This includes support for several validation options as well as a re-design of the `Claims` interface. Lastly, we reworked how errors work under the hood, which should provide a better overall developer experience. Starting from [v5.0.0](https://togithub.com/golang-jwt/jwt/releases/tag/v5.0.0), the import path will be: "github.com/golang-jwt/jwt/v5" For most users, changing the import path *should* suffice. However, since we intentionally changed and cleaned some of the public API, existing programs might need to be updated. The following sections describe significant changes and corresponding updates for existing programs. #### Parsing and Validation Options Under the hood, a new `validator` struct takes care of validating the claims. A long awaited feature has been the option to fine-tune the validation of tokens. This is now possible with several `ParserOption` functions that can be appended to most `Parse` functions, such as `ParseWithClaims`. The most important options and changes are: - Added `WithLeeway` to support specifying the leeway that is allowed when validating time-based claims, such as `exp` or `nbf`. - Changed default behavior to not check the `iat` claim. Usage of this claim is OPTIONAL according to the JWT RFC. The claim itself is also purely informational according to the RFC, so a strict validation failure is not recommended. If you want to check for sensible values in these claims, please use the `WithIssuedAt` parser option. - Added `WithAudience`, `WithSubject` and `WithIssuer` to support checking for expected `aud`, `sub` and `iss`. - Added `WithStrictDecoding` and `WithPaddingAllowed` options to allow previously global settings to enable base64 strict encoding and the parsing of base64 strings with padding. The latter is strictly speaking against the standard, but unfortunately some of the major identity providers issue some of these incorrect tokens. Both options are disabled by default. #### Changes to the `Claims` interface ##### Complete Restructuring Previously, the claims interface was satisfied with an implementation of a `Valid() error` function. This had several issues: - The different claim types (struct claims, map claims, etc.) then contained similar (but not 100 % identical) code of how this validation was done. This lead to a lot of (almost) duplicate code and was hard to maintain - It was not really semantically close to what a "claim" (or a set of claims) really is; which is a list of defined key/value pairs with a certain semantic meaning. Since all the validation functionality is now extracted into the validator, all `VerifyXXX` and `Valid` functions have been removed from the `Claims` interface. Instead, the interface now represents a list of getters to retrieve values with a specific meaning. This allows us to completely decouple the validation logic with the underlying storage representation of the claim, which could be a struct, a map or even something stored in a database. ```go type Claims interface { GetExpirationTime() (*NumericDate, error) GetIssuedAt() (*NumericDate, error) GetNotBefore() (*NumericDate, error) GetIssuer() (string, error) GetSubject() (string, error) GetAudience() (ClaimStrings, error) } ``` ##### Supported Claim Types and Removal of `StandardClaims` The two standard claim types supported by this library, `MapClaims` and `RegisteredClaims` both implement the necessary functions of this interface. The old `StandardClaims` struct, which has already been deprecated in `v4` is now removed. Users using custom claims, in most cases, will not experience any changes in the behavior as long as they embedded `RegisteredClaims`. If they created a new claim type from scratch, they now need to implemented the proper getter functions. ##### Migrating Application Specific Logic of the old `Valid` Previously, users could override the `Valid` method in a custom claim, for example to extend the validation with application-specific claims. However, this was always very dangerous, since once could easily disable the standard validation and signature checking. In order to avoid that, while still supporting the use-case, a new `ClaimsValidator` interface has been introduced. This interface consists of the `Validate() error` function. If the validator sees, that a `Claims` struct implements this interface, the errors returned to the `Validate` function will be *appended* to the regular standard validation. It is not possible to disable the standard validation anymore (even only by accident). Usage examples can be found in [example_test.go](./example_test.go), to build claims structs like the following. ```go // MyCustomClaims includes all registered claims, plus Foo. type MyCustomClaims struct { Foo string `json:"foo"` jwt.RegisteredClaims } // Validate can be used to execute additional application-specific claims // validation. func (m MyCustomClaims) Validate() error { if m.Foo != "bar" { return errors.New("must be foobar") } return nil } ``` #### Changes to the `Token` and `Parser` struct The previously global functions `DecodeSegment` and `EncodeSegment` were moved to the `Parser` and `Token` struct respectively. This will allow us in the future to configure the behavior of these two based on options supplied on the parser or the token (creation). This also removes two previously global variables and moves them to parser options `WithStrictDecoding` and `WithPaddingAllowed`. In order to do that, we had to adjust the way signing methods work. Previously they were given a base64 encoded signature in `Verify` and were expected to return a base64 encoded version of the signature in `Sign`, both as a `string`. However, this made it necessary to have `DecodeSegment` and `EncodeSegment` global and was a less than perfect design because we were repeating encoding/decoding steps for all signing methods. Now, `Sign` and `Verify` operate on a decoded signature as a `[]byte`, which feels more natural for a cryptographic operation anyway. Lastly, `Parse` and `SignedString` take care of the final encoding/decoding part. In addition to that, we also changed the `Signature` field on `Token` from a `string` to `[]byte` and this is also now populated with the decoded form. This is also more consistent, because the other parts of the JWT, mainly `Header` and `Claims` were already stored in decoded form in `Token`. Only the signature was stored in base64 encoded form, which was redundant with the information in the `Raw` field, which contains the complete token as base64. ```go type Token struct { Raw string // Raw contains the raw token Method SigningMethod // Method is the signing method used or to be used Header map[string]interface{} // Header is the first segment of the token in decoded form Claims Claims // Claims is the second segment of the token in decoded form Signature []byte // Signature is the third segment of the token in decoded form Valid bool // Valid specifies if the token is valid } ``` Most (if not all) of these changes should not impact the normal usage of this library. Only users directly accessing the `Signature` field as well as developers of custom signing methods should be affected. #### What's Changed - Added GitHub Actions Markdown by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/260](https://togithub.com/golang-jwt/jwt/pull/260) - Remove `StandardClaims` in favor of `RegisteredClaims` by [@oxisto](https://togithub.com/oxisto) in [#235](https://togithub.com/golang-jwt/jwt/issues/235) - Adding more coverage by [@oxisto](https://togithub.com/oxisto) in [#268](https://togithub.com/golang-jwt/jwt/issues/268) - More consistent way of handling validation errors by [@oxisto](https://togithub.com/oxisto) in [#274](https://togithub.com/golang-jwt/jwt/issues/274) - New Validation API by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/236](https://togithub.com/golang-jwt/jwt/pull/236) - `v5` Pre-Release by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/234](https://togithub.com/golang-jwt/jwt/pull/234) - no need for string slice and call to strings.join by [@moneszarrugh](https://togithub.com/moneszarrugh) in [https://github.com/golang-jwt/jwt/pull/115](https://togithub.com/golang-jwt/jwt/pull/115) - Update MIGRATION_GUIDE.md by [@liam-verta](https://togithub.com/liam-verta) in [https://github.com/golang-jwt/jwt/pull/289](https://togithub.com/golang-jwt/jwt/pull/289) - Moving `DecodeSegement` to `Parser` by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/278](https://togithub.com/golang-jwt/jwt/pull/278) - Adjusting the error checking example by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/270](https://togithub.com/golang-jwt/jwt/pull/270) - add documentation to hmac `Verify` & `Sign` to detail why string is not an advisable input for key by [@dillonstreator](https://togithub.com/dillonstreator) in [https://github.com/golang-jwt/jwt/pull/249](https://togithub.com/golang-jwt/jwt/pull/249) - Add golangci-lint by [@mfridman](https://togithub.com/mfridman) in [https://github.com/golang-jwt/jwt/pull/279](https://togithub.com/golang-jwt/jwt/pull/279) - Added dependabot updates for GitHub actions by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/298](https://togithub.com/golang-jwt/jwt/pull/298) - Bump actions/checkout from 2 to 3 by [@dependabot](https://togithub.com/dependabot) in [https://github.com/golang-jwt/jwt/pull/299](https://togithub.com/golang-jwt/jwt/pull/299) - Bump actions/setup-go from 3 to 4 by [@dependabot](https://togithub.com/dependabot) in [https://github.com/golang-jwt/jwt/pull/300](https://togithub.com/golang-jwt/jwt/pull/300) - Added coverage reporting by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/304](https://togithub.com/golang-jwt/jwt/pull/304) - Last Documentation cleanups for `v5` release by [@oxisto](https://togithub.com/oxisto) in [https://github.com/golang-jwt/jwt/pull/291](https://togithub.com/golang-jwt/jwt/pull/291) - enable jwt.ParsePublicKeyFromPEM to parse PKCS1 Public Key by [@twocs](https://togithub.com/twocs) in [https://github.com/golang-jwt/jwt/pull/120](https://togithub.com/golang-jwt/jwt/pull/120) #### New Contributors - [@moneszarrugh](https://togithub.com/moneszarrugh) made their first contribution in [https://github.com/golang-jwt/jwt/pull/115](https://togithub.com/golang-jwt/jwt/pull/115) - [@liam-verta](https://togithub.com/liam-verta) made their first contribution in [https://github.com/golang-jwt/jwt/pull/289](https://togithub.com/golang-jwt/jwt/pull/289) - [@dillonstreator](https://togithub.com/dillonstreator) made their first contribution in [https://github.com/golang-jwt/jwt/pull/249](https://togithub.com/golang-jwt/jwt/pull/249) - [@dependabot](https://togithub.com/dependabot) made their first contribution in [https://github.com/golang-jwt/jwt/pull/299](https://togithub.com/golang-jwt/jwt/pull/299) - [@twocs](https://togithub.com/twocs) made their first contribution in [https://github.com/golang-jwt/jwt/pull/120](https://togithub.com/golang-jwt/jwt/pull/120) **Full Changelog**: golang-jwt/jwt@v4.5.0...v5.0.0 </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/woodpecker-ci/woodpecker).  --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: qwerty287 <[email protected]>

oxisto changed the title ~~new validation api~~ New validation API Aug 27, 2022

github-actions bot reviewed Aug 27, 2022

View reviewed changes

map_claims.go Outdated Show resolved Hide resolved

map_claims.go Outdated Show resolved Hide resolved

oxisto added this to the v5.0.0 milestone Aug 27, 2022

oxisto added the next The next iteration of development, currently `v6` label Aug 27, 2022

oxisto force-pushed the new-validation-api branch from 115d547 to 1b437d8 Compare August 27, 2022 10:52

This was linked to issues Aug 27, 2022

Bring over ValidationHelper functionality from v4 branch #16

Closed

Token used before issued #98

Closed

oxisto marked this pull request as ready for review August 27, 2022 11:42

oxisto requested review from mfridman, Waterdrips, lggomez and ripienaar August 27, 2022 11:43

oxisto mentioned this pull request Aug 28, 2022

Expiration skew #237

Closed

oxisto linked an issue Aug 28, 2022 that may be closed by this pull request

Expiration skew #237

Closed

oxisto mentioned this pull request Aug 28, 2022

Support for jwt v5 MicahParks/keyfunc#46

Merged

oxisto added 5 commits August 28, 2022 18:18

Fixed linting errors

066f850

GetExpiresAt() -> GetExpirationTime()

0e79f91

Added timeFunc, made iat optional

4990d2c

Added option for audience check

eedf3eb

oxisto force-pushed the new-validation-api branch from 5735b9c to eedf3eb Compare August 28, 2022 16:18

MicahParks suggested changes Oct 15, 2022

View reviewed changes

sermojohn reviewed Oct 26, 2022

View reviewed changes

validator.go Outdated Show resolved Hide resolved

sermojohn reviewed Oct 26, 2022

View reviewed changes

validator.go Outdated Show resolved Hide resolved

oxisto added 3 commits October 26, 2022 19:09

More documentation

06a12c1

exported CustomClaims

2281dd9

Re-enabled map claim tests. Added error return value to claim getter …

5d57c29

…functions

Added more options to check iss and sub

5a65c47

sermojohn reviewed Oct 26, 2022

View reviewed changes

validator.go Show resolved Hide resolved

mfridman reviewed Dec 4, 2022

View reviewed changes

validator.go Outdated Show resolved Hide resolved

mfridman reviewed Dec 4, 2022

View reviewed changes

validator_option.go Outdated Show resolved Hide resolved

mfridman reviewed Dec 4, 2022

View reviewed changes

validator.go Show resolved Hide resolved

mfridman reviewed Dec 4, 2022

View reviewed changes

Simplified Validation API

1d6e6dc

Made validator private for now

2036f52

oxisto requested a review from mfridman December 5, 2022 10:43

mfridman approved these changes Dec 5, 2022

View reviewed changes

oxisto merged commit 3d20909 into v5 Dec 5, 2022

oxisto deleted the new-validation-api branch December 5, 2022 13:56

oxisto mentioned this pull request Dec 9, 2022

Cleanup and documentation of verification functions #262

Merged

oxisto linked an issue Feb 17, 2023 that may be closed by this pull request

TimeFunc being static prevents from using this package in a parallel test #188

Closed

renovate bot mentioned this pull request Sep 5, 2023

fix(deps): update shared components packages (major) redhat-developer/app-services-cli#1765

Open

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New validation API #236

New validation API #236

oxisto commented Aug 27, 2022 •

edited

Loading

oxisto commented Aug 27, 2022 •

edited

Loading

MicahParks commented Sep 26, 2022

oxisto commented Sep 26, 2022

b4k3r commented Sep 30, 2022

oxisto commented Sep 30, 2022

oxisto commented Oct 15, 2022

MicahParks commented Oct 15, 2022

MicahParks commented Oct 15, 2022 •

edited

Loading

sermojohn commented Oct 26, 2022

oxisto commented Oct 26, 2022

oxisto commented Dec 3, 2022

mfridman Dec 4, 2022

oxisto Dec 4, 2022

mfridman Dec 5, 2022

oxisto Dec 5, 2022

mfridman left a comment

oxisto commented Dec 4, 2022

mfridman commented Dec 4, 2022

oxisto commented Dec 5, 2022

mfridman left a comment

tschaub commented Apr 4, 2023

New validation API #236

New validation API #236

Conversation

oxisto commented Aug 27, 2022 • edited Loading

oxisto commented Aug 27, 2022 • edited Loading

MicahParks commented Sep 26, 2022

oxisto commented Sep 26, 2022

b4k3r commented Sep 30, 2022

oxisto commented Sep 30, 2022

oxisto commented Oct 15, 2022

MicahParks commented Oct 15, 2022

MicahParks commented Oct 15, 2022 • edited Loading

sermojohn commented Oct 26, 2022

oxisto commented Oct 26, 2022

oxisto commented Dec 3, 2022

mfridman Dec 4, 2022

Choose a reason for hiding this comment

oxisto Dec 4, 2022

Choose a reason for hiding this comment

mfridman Dec 5, 2022

Choose a reason for hiding this comment

oxisto Dec 5, 2022

Choose a reason for hiding this comment

mfridman left a comment

Choose a reason for hiding this comment

oxisto commented Dec 4, 2022

mfridman commented Dec 4, 2022

oxisto commented Dec 5, 2022

mfridman left a comment

Choose a reason for hiding this comment

tschaub commented Apr 4, 2023

oxisto commented Aug 27, 2022 •

edited

Loading

oxisto commented Aug 27, 2022 •

edited

Loading

MicahParks commented Oct 15, 2022 •

edited

Loading