jwx

github.com/lestrrat-go/jwx/v4

Go module implementing various JWx (JWA/JWE/JWK/JWS/JWT, otherwise known as JOSE) technologies.

If you are using this module in your product or your company, please add your product and/or company name in the Wiki! It really helps keeping up our motivation.

Requirements

• Go 1.26 or later
• GOEXPERIMENT=jsonv2, on Go 1.26 only

v4 uses encoding/json/v2, which sits behind GOEXPERIMENT=jsonv2 on Go 1.26 and is part of the standard library from Go 1.27 on. On Go 1.27 leave GOEXPERIMENT unset: naming an experiment the toolchain already ships rebuilds the standard library under a non-default configuration for no benefit.

Install

go get github.com/lestrrat-go/jwx/v4

Claude Code Skill

If you use Claude Code, install the bundled jwx-dev-v4 skill so the assistant can guide you through using this library — picking algorithms, parsing/signing JWTs, working with JWS/JWE/JWK, and avoiding common footguns:

/plugin marketplace add lestrrat-go/jwx
/plugin install jwx-dev-v4

The skill is scoped to v4 only. It is intended for developers using jwx, not for working on the library itself.

Migrating from v3

If you are migrating from github.com/lestrrat-go/jwx/v3, see MIGRATION.md for a step-by-step guide with before/after code examples. For a complete list of breaking changes and new features, see Changes-v4.md.

Features

Feature Description Complete JWA/JWE/JWK/JWS/JWT coverage Not just JWT + minimum tool set. Supports JWS messages with multiple signatures (compact and JSON serialization), JWS with detached payload, JWS with unencoded payload (RFC 7797), JWE messages with multiple recipients (compact and JSON serialization). Most operations work with either JWK or raw keys (e.g. *rsa.PrivateKey, *ecdsa.PrivateKey). Opinionated, uniform API Everything is symmetric and follows a standard convention: jws.Parse/Verify/Sign, jwe.Parse/Encrypt/Decrypt. Arguments are organized as explicit required parameters and optional WithXXXX() style options. Post-quantum cryptography Supports ML-KEM, ML-DSA, and HPKE. Extension module architecture Opt-in features via extension modules. See Extension Modules. JWK Caching jwkfetch extension to always keep a JWKS up-to-date. Bazel Support Bazel-ready.

SYNOPSIS

…

source: examples/jwx_readme_example_test.go

Documentation

• API Reference
• How-to Documentation
• Runnable Examples
• Extension Modules

Packages and Standards

This module implements the following specifications:

Package Specification jwa RFC 7518 (JSON Web Algorithms) jwk RFC 7517 (JSON Web Key), RFC 7638 (JWK Thumbprint), RFC 8037 (CFRG Curves) jws RFC 7515 (JSON Web Signature), RFC 7797 (Unencoded Payload) jwe RFC 7516 (JSON Web Encryption), draft-ietf-jose-hpke-encrypt (HPKE) jwt RFC 7519 (JSON Web Token)

Additionally supported via the main module or extension modules:

Specification Support FIPS 203 (ML-KEM) JWE key encapsulation via github.com/jwx-go/mlkem: ML-KEM-768, ML-KEM-1024, hybrid variants (draft-ietf-jose-pqc-kem) FIPS 204 (ML-DSA) JWS signatures: native from Go 1.27 on, via github.com/jwx-go/mldsa on Go 1.26 (details)

History

My goal was to write a server that heavily uses JWK and JWT. At first glance the libraries that already exist seemed sufficient, but soon I realized that

1. To completely implement the protocols, I needed the entire JWT, JWK, JWS, JWE (and JWA, by necessity).
2. Most of the libraries that existed only deal with a subset of the various JWx specifications that were necessary to implement their specific needs

For example, a certain library looks like it had most of JWS, JWE, JWK covered, but then it lacked the ability to include private claims in its JWT responses. Another library had support of all the private claims, but completely lacked in its flexibility to generate various different response formats.

Because I was writing the server side (and the client side for testing), I needed the entire JOSE toolset to properly implement my server, and they needed to be flexible enough to fulfill the entire spec that I was writing.

So here's github.com/lestrrat-go/jwx/v4. This library is extensible, customizable, and hopefully well organized to the point that it is easy for you to slice and dice it.

Why would I use this library?

There are several other major Go modules that handle JWT and related data formats, so why should you use this library?

From a purely functional perspective, the only major difference is this: Whereas most other projects only deal with what they seem necessary to handle JWTs, this module handles the entire spectrum of JWS, JWE, JWK, and JWT.

That is, if you need to not only parse JWTs, but also to control JWKs, or if you need to handle payloads that are NOT JWTs, you should probably consider using this module. You should also note that JWT is built on top of those other technologies. You simply cannot have a complete JWT package without implementing the entirety of JWS/JWE/JWK, which this library does.

Next, from an implementation perspective, this module differs significantly from others in that it tries very hard to expose only the APIs, and not the internal data. For example, individual JWT claims are not accessible through struct field lookups. You need to use one of the getter methods.

This is because this library takes the stance that the end user is fully capable and even willing to shoot themselves on the foot when presented with a lax API. By making sure that users do not have access to open structs, we can protect users from doing silly things like creating incomplete structs, or access the structs concurrently without any protection. This structure also allows us to put extra smarts in the structs, such as doing the right thing when you want to parse / write custom fields (this module does not require the user to specify alternate structs to parse objects with custom fields)

In the end I think it comes down to your usage pattern, and priorities. Some general guidelines that come to mind are:

• If you want a single library to handle everything JWx, such as using JWE, JWK, JWS, handling auto-refreshing JWKs, use this module.
• If you want to honor all possible custom fields transparently, use this module.
• If you want a standardized clean API, use this module.

Otherwise, feel free to choose something else.

Contributions

Issues

For bug reports and feature requests, please try to follow the issue templates as much as possible. For either bug reports or feature requests, failing tests are even better.

Pull Requests

Please make sure to include tests that exercise the changes you made.

If you are editing auto-generated files (those files with the _gen.go suffix, please make sure that you do the following:

1. Edit the generator, not the generated files (e.g. internal/jwxcodegen/cmd/jwxcodegen/)
2. Run make generate (or go generate) to generate the new code
3. Commit both the generator and the generated files

Discussions / Usage

Please try discussions first.

Credits

• Initial work on this library was generously sponsored by HDE Inc (https://www.hde.co.jp)
• Lots of code, especially JWE was initially taken from go-jose library (https://github.com/square/go-jose)
• Lots of individual contributors have helped this project over the years. Thank each and everyone of you very much.

Quid pro quo

If you use this software to build products in a for-profit organization, we ask you to consider contributing back to FOSS in the following manner:

• For every 100 employees (direct hires) of your organization, please consider contributing minimum of $1 every year to either this project, or another FOSS projects that this project uses. For example, for 100 employees, we ask you contribute $100 yearly; for 10,000 employees, we ask you contribute $10,000 yearly.
• If possible, please make this information public. You do not need to disclose the amount you are contributing, but please make the information that you are contributing to particular FOSS projects public. For this project, please consider writing your name on the Wiki

This is NOT a licensing term: you are still free to use this software according to the license it comes with. This clause is only a plea for people to acknowledge the work from FOSS developers whose work you rely on each and everyday.