NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
Go modules
Last release 15 days ago
14 Sep 2026
Ships fairly regularly
a new release about every 3 weeks
Nearly every release is documented
notes for 8 of 8 stable releases
Nothing withdrawn
no release was ever pulled
4 years old
86 releases · first in 2022
One column per quarter.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
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 add…
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 for all the reviews, all contributors for their commits and of course @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, on behalf of @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, 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.
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:
WithLeeway to support specifying the leeway that is allowed when validating time-based claims, such as exp or nbf.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.WithAudience, WithSubject and WithIssuer to support checking for expected aud, sub and iss.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.Claims interfacePreviously, the claims interface was satisfied with an implementation of a Valid() error function. This had several issues:
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.
type Claims interface {
GetExpirationTime() (*NumericDate, error)
GetIssuedAt() (*NumericDate, error)
GetNotBefore() (*NumericDate, error)
GetIssuer() (string, error)
GetSubject() (string, error)
GetAudience() (ClaimStrings, error)
}StandardClaimsThe 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.
ValidPreviously, 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, to build claims structs like the following.
// 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
}Token and Parser structThe 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.
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.
StandardClaims in favor of RegisteredClaims by @oxisto in #235v5 Pre-Release by @oxisto in #234DecodeSegement to Parser by @oxisto in #278Verify & Sign to detail why string is not an advisable input for key by @dillonstreator in #249v5 release by @oxisto in #291Full Changelog: v4.5.0...v5.0.0
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →