enable jwt.ParsePublicKeyFromPEM to parse PKCS1 Public Key #120
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
oxisto
reviewed
Nov 16, 2021
…olang-jwt#34) * remove unnecessary for loop in token signing string for readability - add testcase - add benchmark - improve performance slightly * Fix benchtests on token_test.go * Update token_test.go to v4 Co-authored-by: hyeonjae <hyeonjae@ip-192-168-1-3.ap-northeast-2.compute.internal> Co-authored-by: Luis Gabriel Gomez <lggomez@users.noreply.github.com>
* updated README.md to contain more extensions * Update README.md Co-authored-by: Luis Gabriel Gomez <lggomez@users.noreply.github.com> Co-authored-by: Luis Gabriel Gomez <lggomez@users.noreply.github.com>
Co-authored-by: Kolawole Segun <Kolawole.Segun@kyndryl.com> Co-authored-by: Christian Banse <oxisto@aybaze.com>
This reverts commit d489c99.
Signed-off-by: jay-dee7 <jasdeepsingh.uppal@gmail.com> Co-authored-by: jay-dee7 <jasdeepsingh.uppal@gmail.com>
Co-authored-by: Christian Banse <oxisto@aybaze.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"
* Bump matrix to support latest go version (go1.19) * Fix comment
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 golang/go#15656. Signed-off-by: Alexander Yastrebov <yastrebov.alex@gmail.com>
Co-authored-by: Micah Parks <66095735+MicahParks@users.noreply.github.com> Co-authored-by: Michael Fridman <mf192@icloud.com>
* Update MIGRATION_GUIDE.md Saw one typo, spent a few minutes improving a few paragraphs.
* 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
This PR adjusts the error checking example so that a check for an invalid signature is also included. See discussion in golang-jwt#143
oxisto
approved these changes
Mar 29, 2023
|
@twocs Sorry that this PR was stale for such a long time. I took the liberty of fixing the two outstanding comments and merging in the current main. Now all conflicts are gone and we should be good to go. |
1 task
qwerty287
added a commit
to woodpecker-ci/woodpecker
that referenced
this pull request
Sep 13, 2023
[](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 [golang-jwt/jwt#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 [golang-jwt/jwt#236 - `v5` Pre-Release by [@​oxisto](https://togithub.com/oxisto) in [golang-jwt/jwt#234 - no need for string slice and call to strings.join by [@​moneszarrugh](https://togithub.com/moneszarrugh) in [golang-jwt/jwt#115 - Update MIGRATION_GUIDE.md by [@​liam-verta](https://togithub.com/liam-verta) in [golang-jwt/jwt#289 - Moving `DecodeSegement` to `Parser` by [@​oxisto](https://togithub.com/oxisto) in [golang-jwt/jwt#278 - Adjusting the error checking example by [@​oxisto](https://togithub.com/oxisto) in [golang-jwt/jwt#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 [golang-jwt/jwt#249 - Add golangci-lint by [@​mfridman](https://togithub.com/mfridman) in [golang-jwt/jwt#279 - Added dependabot updates for GitHub actions by [@​oxisto](https://togithub.com/oxisto) in [golang-jwt/jwt#298 - Bump actions/checkout from 2 to 3 by [@​dependabot](https://togithub.com/dependabot) in [golang-jwt/jwt#299 - Bump actions/setup-go from 3 to 4 by [@​dependabot](https://togithub.com/dependabot) in [golang-jwt/jwt#300 - Added coverage reporting by [@​oxisto](https://togithub.com/oxisto) in [golang-jwt/jwt#304 - Last Documentation cleanups for `v5` release by [@​oxisto](https://togithub.com/oxisto) in [golang-jwt/jwt#291 - enable jwt.ParsePublicKeyFromPEM to parse PKCS1 Public Key by [@​twocs](https://togithub.com/twocs) in [golang-jwt/jwt#120 #### New Contributors - [@​moneszarrugh](https://togithub.com/moneszarrugh) made their first contribution in [golang-jwt/jwt#115 - [@​liam-verta](https://togithub.com/liam-verta) made their first contribution in [golang-jwt/jwt#289 - [@​dillonstreator](https://togithub.com/dillonstreator) made their first contribution in [golang-jwt/jwt#249 - [@​dependabot](https://togithub.com/dependabot) made their first contribution in [golang-jwt/jwt#299 - [@​twocs](https://togithub.com/twocs) made their first contribution in [golang-jwt/jwt#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. --- - [ ] <!-- rebase-check -->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). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi44My4wIiwidXBkYXRlZEluVmVyIjoiMzYuODMuMCIsInRhcmdldEJyYW5jaCI6Im1haW4ifQ==--> --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: qwerty287 <ndev@web.de>
](https://renovatebot.com){kind=link}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#119
The code comment for jwt.ParsePublicKeyFromPEM stated that it could parse PKCS1 public keys.
However, it couldn't. I created a unit test that generates a public PKCS1 key and the function cannot pass the test.
I have added an extra attempt to parse the public key via the x509.ParsePKCS1PublicKey function, but also retained previous functionality that attempts to parse it from PKIX or certificate first.