go-jose

go-jose is a Go implementation of the JOSE (JSON Object Signing and Encryption) family of standards, covering JSON Web Encryption (RFC 7516), JSON Web Signature (RFC 7515), and JSON Web Token (RFC 7519) in a single library. It supports both compact and full JWS/JWE JSON serialization, multi-recipient encryption, and nearly the entire algorithm surface defined by the JOSE RFCs, including RSA-OAEP, AES key wrap, ECDH-ES, AES-GCM key wrap, PBES2, HMAC, RSASSA, ECDSA, and EdDSA.

The library ships as github.com/go-jose/go-jose/v4, with JWT-specific helpers factored into a jwt subpackage and a small jose-util CLI for working with JOSE messages from a shell. It also vendors a forked version of Go’s encoding/json that enforces case-sensitive member matching, closing a class of interoperability bugs between go-jose and JOSE implementations in other languages. Maintained under the go-jose GitHub organization, the successor to Square’s original square/go-jose, it is one of the most widely depended-on cryptography libraries in the Go ecosystem.

What You Get

• Full JWE/JWS/JWT support - encrypt, sign, and parse JSON Web Encryption, Signature, and Token objects in both compact and JSON serialization forms.
• Broad algorithm coverage - RSA-OAEP, AES key wrap, AES-GCM key wrap, ECDH-ES, PBES2, HMAC, RSASSA-PKCS1/PSS, ECDSA, and EdDSA out of the box.
• Multi-recipient encryption - a single JWE can be encrypted to multiple recipients using different key algorithms.
• jwt subpackage - a typed JSONWebToken/Builder API with standard and custom claim validation (issuer, audience, expiry, not-before).
• jose-util CLI - a bundled command-line tool for generating keys and signing/encrypting/decrypting JOSE messages from a shell.

Common Use Cases

• Issuing and verifying JWTs - authentication services sign and validate access or ID tokens without depending on a bespoke JWT-only library.
• Encrypting sensitive payloads for storage or transit - services use JWE to encrypt data such as PII or session state that must be decrypted only by the holder of a specific key.
• Interop with non-Go JOSE implementations - the case-sensitive JSON fork and full RFC algorithm coverage make go-jose a safe choice when tokens must round-trip with clients in other languages.
• Building custom identity or SSO systems - the low-level Encrypter/Signer interfaces let teams compose their own token issuance and verification flows on top of standards-compliant primitives.

Under The Hood

Architecture

The library is organized around a small set of interfaces: Encrypter/Decrypter for JWE, Signer/Verifier for JWS, each backed by pluggable strategy types (contentCipher, keyGenerator, keyEncrypter, keyDecrypter in crypter.go) selected by KeyAlgorithm/ContentEncryption/SignatureAlgorithm string constants. JWT support in the jwt subpackage builds strictly on top of the base jose package’s ParseSignedCompact/ParseEncryptedCompact rather than duplicating serialization logic, and the jose-util CLI is a thin consumer of the same public API. This keeps the crypto core (asymmetric.go, symmetric.go, signing.go) fully decoupled from both serialization (jws.go, jwe.go) and the higher-level JWT convenience layer, so adding a new algorithm means implementing one interface rather than touching call sites throughout the codebase.

Tech Stack

Written in pure Go (module targets Go 1.24) with no external runtime dependencies, relying entirely on the standard library’s crypto/rsa, crypto/ecdsa, crypto/ed25519, and crypto/elliptic packages for primitives. The repository vendors its own fork of encoding/json (in the json subpackage) to enforce case-sensitive struct tag matching, since JOSE’s JSON serialization is security-sensitive to case handling. CI runs go build and go test across two current Go release lines plus a scheduled govulncheck job, and the jose-util CLI subdirectory is exercised separately with cram-based shell tests.

Code Quality

The project carries an extensive test suite, roughly one test file per production file (35 _test.go files against under 30 non-test .go files), plus dedicated fuzz targets for JWE, JWS, and JWT parsing under the fuzz directory. Errors are represented as package-level sentinel values (ErrCryptoFailure, ErrUnsupportedAlgorithm, ErrInvalidKeySize, etc.) that callers can compare against directly, rather than opaque strings, and exported types and functions carry doc comments throughout. CI enforces the test suite and a vulnerability scan on every push and pull request across supported Go versions.

What Makes It Unique

go-jose is one of the few Go libraries that implements the JOSE standards as a coherent whole, JWE, JWS, and JWT together, rather than a JWT-only convenience wrapper around ad hoc signing code. Its case-sensitive JSON fork addresses a specific, easy-to-miss interoperability failure mode when Go services exchange tokens with implementations in other languages, and its algorithm coverage (including PBES2 password-based key wrapping and full ECDH-ES support) goes well beyond what most JWT-focused libraries expose.