An implementation of JOSE standards (JWE, JWS, JWT) in Go



godoc godoc license build coverage

Package jose aims to provide an implementation of the Javascript Object Signing and Encryption set of standards. This includes support for JSON Web Encryption, JSON Web Signature, and JSON Web Token standards.

Disclaimer: This library contains encryption software that is subject to the U.S. Export Administration Regulations. You may not export, re-export, transfer or download this code or any part of it in violation of any United States law, directive or regulation. In particular this software may not be exported or re-exported in any form or on any media to Iran, North Sudan, Syria, Cuba, or North Korea, or to denied persons or entities mentioned on any US maintained blocked list.


The implementation follows the JSON Web Encryption (RFC 7516), JSON Web Signature (RFC 7515), and JSON Web Token (RFC 7519) specifications. Tables of supported algorithms are shown below. The library supports both the compact and JWS/JWE JSON Serialization formats, and has optional support for multiple recipients. It also comes with a small command-line utility (jose-util) for dealing with JOSE messages in a shell.

Note: We use a forked version of the encoding/json package from the Go standard library which uses case-sensitive matching for member names (instead of case-insensitive matching). This is to avoid differences in interpretation of messages between go-jose and libraries in other languages.


Version 2 (branch, doc) is the current stable version:

import ""

Version 3 (branch, doc) is the under development/unstable version (not released yet):

import ""

All new feature development takes place on the master branch, which we are preparing to release as version 3 when it's ready. Version 2 will continue to receive critical bug and security fixes. Note that starting with version 3 we are using Go modules for versioning instead of as before.

Version 1 (on the v1 branch) is frozen and not supported anymore.

Supported algorithms

See below for a table of supported algorithms. Algorithm identifiers match the names in the JSON Web Algorithms standard where possible. The Godoc reference has a list of constants.

Key encryption Algorithm identifier(s)
RSA-PKCS#1v1.5 RSA1_5
AES key wrap A128KW, A192KW, A256KW
AES-GCM key wrap A128GCMKW, A192GCMKW, A256GCMKW
ECDH-ES (direct) ECDH-ES1
Direct encryption dir1

1. Not supported in multi-recipient mode

Signing / MAC Algorithm identifier(s)
RSASSA-PKCS#1v1.5 RS256, RS384, RS512
RSASSA-PSS PS256, PS384, PS512
HMAC HS256, HS384, HS512
ECDSA ES256, ES384, ES512
Ed25519 EdDSA2

2. Only available in version 2 of the package

Content encryption Algorithm identifier(s)
AES-CBC+HMAC A128CBC-HS256, A192CBC-HS384, A256CBC-HS512
Compression Algorithm identifiers(s)

Supported key types

See below for a table of supported key types. These are understood by the library, and can be passed to corresponding functions such as NewEncrypter or NewSigner. Each of these keys can also be wrapped in a JWK if desired, which allows attaching a key id.

Algorithm(s) Corresponding types
RSA *rsa.PublicKey, *rsa.PrivateKey
ECDH, ECDSA *ecdsa.PublicKey, *ecdsa.PrivateKey
EdDSA1 ed25519.PublicKey, ed25519.PrivateKey
AES, HMAC []byte

1. Only available in version 2 or later of the package


godoc godoc

Examples can be found in the Godoc reference for this package. The jose-util subdirectory also contains a small command-line utility which might be useful as an example as well.

  • jwe using Curve P521, ECDH-ES, and A256GCM does not always work with with other implementations

    jwe using Curve P521, ECDH-ES, and A256GCM does not always work with with other implementations

    I am not able to encrypt/decrypt within Java and Go using Curve P521, ECDH-ES, and A256GCM using the same values for curve X, Y, and D. When I try to take the encrypted value from Java and Decrypt in Go it fails (about half the time) and vice versa it fails with:

    Go: square/go-jose: error in cryptographic primitive

    Sometimes it works though.

    I am manually creating the KeyPair in both programs with the same X, Y, and D. Here is a link to my stackoverflow question.

    bug help wanted 
    opened by dodgeware 23
  • Custom headers and additional header support

    Custom headers and additional header support

    The JWE spec supports more than just the two fields allowed currently in go-jose (alg and enc). You can also specify a kid which is really important when using symmetric encryption like AES with JWE.

    I'm attempting something like so:

        alg := jose.KeyAlgorithm("dir")
        enc := jose.ContentEncryption("A256GCM")
        encrypter, err := jose.NewEncrypter(alg, enc, resp.Plaintext)
        if err != nil {
        obj, err := encrypter.Encrypt([]byte(contents))
        obj.Header.KeyID = "XXXXXX"

    but when I attempt to base64 decode the header (first part), I still only see alg and enc.

    I'm proposing either changing the Encrypter interface to support new funcs for adding kid specifically or a more generic one to allow setting headers that are unrelated to the encryption and key methods being used.

    I can maybe make a PR on this but I need to know which way you'd rather go first.


    enhancement help wanted 
    opened by lusis 16
  • support asymmetric signing and verification with opaque keys

    support asymmetric signing and verification with opaque keys

    This enables signing with crypto oracles.

    opened by mikedanese 12
  • Claims encoding/decoding

    Claims encoding/decoding

    Claims represented as concrete type.

    Follows JWT spec on interpretation of claim fields values, namely:

    • NumericDate can be represented as either int or float
    • Audience can be either string or array of strings

    Timestamps are normalized by checking Time.IsZero, otherwise negative timestamp values would show up in encoded JSON.

    Validator is checking Expiry/NotBefore using leeway as indicated in a spec. Current time is provided as argument to Validator.Validate call. Unit tests for validator are still pending.

    opened by shaxbee 12
  • Export Unverified Payload

    Export Unverified Payload

    I want to access JWS payload before it gets verified.

    Use Case: I am building an Open ID Connect clients which accepts ID Tokens (i.e. JWTs signed by JWS) issued by multiple issuers. In this client, parse a JWS payload at first, then recognize the issuer by iss claim of the payload and retrieve JWKs via Open ID Connect Discovery flow, finally verify the JWS using retrieved JWKs.

    I looked for a go-jose's API that exports an unverified JWS payload but could not find. Do you have any plans to support this use case?

    opened by yosida95 12
  • x5c / x5t parameters

    x5c / x5t parameters

    Is it possible to use x5c parameters with go-jose? I want to marshall a RSA private key along a x509 certificate (for HTTP over TLS).


    opened by aeneasr 12
  • optional date claims

    optional date claims

    Solves #219

    opened by nelz9999 12
  • Switch to case-sensitive encoding/json fork

    Switch to case-sensitive encoding/json fork

    r: @alokmenghrajani @mcpherrinm @sqshh @jsha @rolandshoemaker

    Fixes issue #73 by switching to a forked, case-sensitive version of encoding/json (from Go 1.6).

    Changes in square/go-jose:

    • Switch to forked json package
    • Add tests for case-sensitive parsing behavior
    • Drop Go 1.2 support (broken with forked json)

    Changes in the forked encoding/json package:

    • Remove fold.go, fold_test.go (contained case-sensitive folding functions)
    • Set equalFold to be bytes.Equal in encode.go (no more case-sensitive matching)
    • Removed example_test.go (broke build on older Go versions)

    Also updated some of the test cases in the forked json package, as they were depending on the case-insensitive parsing behavior. In particular, decode_test.go (c.f Ambig struct) was updated.

    opened by csstaub 10
  • Support Base64URL-encoded

    Support Base64URL-encoded "n" parameter in JSONWebKey

    The JWA spec says:

    The "n" (modulus) parameter contains the modulus value for the RSA public key. It is represented as a Base64urlUInt-encoded value.

    However, Base64URL-encoded "n" parameter cannot be unmarshalled into JSONWebKey in go-jose.

    Here is what I'm trying to do:

    var d jose.JSONWebKeySet
    if err := json.Unmarshal(body, &d); err != nil {
    	return err

    When the "n" parameter in the json body is Base64URL encoded instead of Base64 encoded, I get the error illegal base64 data at input byte 343. I think this is because encoding/json package expects a Base64-encoded string when decoding to []byte.

    Not sure if I'm missing something?

    This can be solved by changing the type of N in rawJSONWebKey to string. If I'm right, let me know, I'll gladly submit a PR.

    opened by yun-wang 10
  • Add support for PBES2 Key algorithms

    Add support for PBES2 Key algorithms

    Add functionality to support for password-based cryptography with the optional key algorithms:

    • PBES2-HS256+A128KW
    • PBES2-HS384+A192KW
    • PBES2-HS512+A256KW

    PBES2 algorithms require two new parameters in the header p2c (pbkdf2 number of iterations) and p2s (salt). I added those parameters in the recipient and they are optional. Safe defaults are used if they are left empty, 100,000 for the count and a 128 bits salt. NIST recommendation is at least 10,000, but some applications like 1Password are already using 100k.

    I'm open to suggestions, do a PR for the master branch, change the defaults, or use EncrypterOptions to add the extra parameters instead of the recipient.

    opened by maraino 10
  • ES256/etc algs produce non-deterministic ECDSA signatures inconsistent with the IETF JWT BCP

    ES256/etc algs produce non-deterministic ECDSA signatures inconsistent with the IETF JWT BCP

    In go-jose the ES256/ES384/ES512 algorithms that use ECDSA have been implemented to produce non-deterministic signatures. This means that signing the same JWT payload repeatedly produces a different signature each time.

    According to the IETF JSON Web Token Best Current Practices Section 3.2 (JWT BCP) it is best practice to produce deterministic ECDSA signatures as defined by RFC6979 because of the possibility of recovering the private key when non-deterministic ECDSA signatures are used.

    The JWT BCP states that:

    ECDSA signatures require a unique random value for every message that is signed. If even just a few bits of the random value are predictable across multiple messages then the security of the signature scheme may be compromised. In the worst case, the private key may be recoverable by an attacker.

    The JWT BCP goes on to state:

    To counter these attacks, JWT libraries SHOULD implement ECDSA using the deterministic approach defined in [RFC6979]. This approach is completely compatible with existing ECDSA verifiers and so can be implemented without new algorithm identifiers being required.

    Digging into the code, it looks like go-jose uses the Go stdlib's "crypto/rand".Reader as the random input into "crypto/ecdsa".Sign to produce the non-deterministic signature. I think the relevant code is here:

    According to the godocs for "crypto/ecdsa".Sign:

    The security of the private key depends on the entropy of rand.

    My interpretation of the above (don't rely on it, I am often wrong) is that this is fine as long as RandReader is unpredictable, but it'd be great if the library followed the JWT Best Current Practices and wasn't dependent on that assumption.

    Thanks to @juli and @marcelosalloum for identifying the changing signatures and inconsistency with the JWT BCP.

    People tell me this isn't a vulnerability and isn't sensitive, but I took the conservative approach of emailing [email protected] first. There is no security policy on this GitHub repo, and that's the only email I could find. After a couple weeks and multiple emails I didn't receive a response, so I'm posting here.

    opened by leighmcculloch 2
  • It is not possible to configure json decoder when unmarshalling JSONWebToken's claims

    It is not possible to configure json decoder when unmarshalling JSONWebToken's claims


    Currently methods JSONWebToken.Claims and JSONWebToken.UnsafeClaimsWithoutVerification use default json decoding settings and there is no way to modify them e.g. setting Decoder.SetNumberType.

    Current workaround

    Implementing a custom unmarshal and set decoder settings e.g.

    type MapClaims map[string]interface{}
    func (m MapClaims) UnmarshalJSON(b []byte) error {
    	d := json.NewDecoder(bytes.NewReader(b))
    	// this prevents stack overflow
    	mp := map[string]interface{}(m)
    	return d.Decode(&mp)

    Proposed Solutions

    Option 1 Create a DecodeOption type that can be passed as a trailing dest arg in variadic func .Claims and .UnsafeClaimsWithoutVerification methods to configure the json decoder

    Option 2 Add a DecodingOptions field to JSONWebToken struct that is used to configure JSON decoder in Claims and UnsafeClaimsWithoutVerification methods

    Option 3 Global settings? kind of ugly

    Option 4 Keep using the workaround

    In order of preference I like Options 1 and 2. Option 1 is very convenient, it does not alter any struct and there is no need to keep any state. The disadvantage is that it is not that obvious, but we can document it.

    opened by narg95 0
  • json.Unmarshal converts json literal integer to float64 instead of int64 when taget type is of type interface{}

    json.Unmarshal converts json literal integer to float64 instead of int64 when taget type is of type interface{}


    json.Unmarshal unmarshals integers values into float64 when target type is of type interface{}.

    Expected behavior

    If a json literal is assignable to an integer without losing precision the json.Unmarshal must convert to int64 instead of float64

    The problem is located in json/decode.go in convertNumber function:

    func (d *decodeState) convertNumber(s string) (interface{}, error) {
    	if d.useNumber {
    		return Number(s), nil
    	f, err := strconv.ParseFloat(s, 64)  // See here! By default it converts to Float
    	if err != nil {
    		return nil, &UnmarshalTypeError{"number " + s, reflect.TypeOf(0.0), int64(}
    	return f, nil

    by default it does strconv.ParseFloat

    Steps to Reproduce

    func TestUnmarshalNumber(t *testing.T) {
    	var v interface{}
    	exp := int64(1621867181)
    	err := json.Unmarshal([]byte(`1621867181`), &v)
    	require.NoError(t, err)
    	require.IsType(t, exp, v)


    === RUN   TestUnmarshalNumber
            	Error Trace:	token_test.go:502
            	Error:      	Object expected to be of type int64, but was float64
            	Test:       	TestUnmarshalNumber
    --- FAIL: TestUnmarshalNumber (0.00s)
    FAIL	token/jwt	0.025s

    Proposed Solution

    convertNumber should try first strconv.ParseInt and in case of err it does strconv.ParseFloat

    If you agree with the proposal I can submit a PR

    opened by narg95 7
  • x5u header doesn't work

    x5u header doesn't work

    If you have the x5u header in a JWK you get the error json: cannot unmarshal string into Go value of type url.URL

    I have a fix for v3 here:

    opened by bouk 0
  • What is going on with v3?

    What is going on with v3?

    Hi, I want to adopt this module for my project, but I'm a bit unclear about what's happening. It seems you've forked it to go-jose/go-jose, but then that one still has the module name so I can't import it (with go get -u[email protected]).

    How am I supposed to use it?

    opened by bouk 8
  • Using MultiEncrypter with ContentType

    Using MultiEncrypter with ContentType

    Right now in NewMultiEncrypter the ExtraHeaders from the options object is never copied to the encrypter. This means you can't make an encrypter that will satisfy the NestedBuilder requirement of having a "JWT" content type.

    Here is an example of v2 and this behavior:

    Here is an example of v3 showing this behavior:

    Is there something I'm missing or is this expected behavior for some reason?

    opened by kelsin 1
  • Dependabot couldn't find a go.mod for this project

    Dependabot couldn't find a go.mod for this project

    Dependabot couldn't find a go.mod for this project.

    Dependabot requires a go.mod to evaluate your project's current Go dependencies. It had expected to find one at the path: /go.mod.

    If this isn't a Go project, or if it is a library, you may wish to disable updates for it from within Dependabot.

    View the update logs.

    opened by dependabot-preview[bot] 0
  • The example for making encrypted JWTs doesn't work

    The example for making encrypted JWTs doesn't work

    Execute the code example found here:

    The resulting JWT token is invalid, it has no contents


    opened by asilverman 2
  • is Expiry checked?

    is Expiry checked?

    Seems be Expiry must be manual check instead of automatic checking. Seems wrong implementation

    package main
    import (
    func main() {
    	ttl := 2
    	sharedKey := []byte("foobar")
    	signer, err := jose.NewSigner(jose.SigningKey{Algorithm: jose.HS256, Key: sharedKey}, (&jose.SignerOptions{}).WithType("JWT"))
    	if err != nil {
    	Expiry := time.Now().UTC()
    	Expiry = Expiry.UTC().Add(time.Second * time.Duration(ttl))
    	claim := jwt.Claims{
    		NotBefore: jwt.NewNumericDate(time.Now().UTC()),
    		Expiry:    jwt.NewNumericDate(Expiry),
    	fmt.Println("Sign time is: ")
    	fmt.Println("Expiry time is: ")
    	token, err := jwt.Signed(signer).Claims(claim).CompactSerialize()
    	if err != nil {
    	parsed, err := jwt.ParseSigned(token)
    	if err != nil {
    	fmt.Println("First validation time is: ")
    	out := jwt.Claims{}
    	if err := parsed.Claims(sharedKey, &out); err != nil {
    	fmt.Println("Waiting for time to get Expiry limit")
    	time.Sleep(4 * time.Second)
    	fmt.Println("OK lets parse and check again")
    	parsed2, err := jwt.ParseSigned(token)
    	if err != nil {
    	fmt.Println("Second invalid validation time is: ")
    	out2 := jwt.Claims{}
    	if err := parsed2.Claims(sharedKey, &out2); err != nil {
    	fmt.Println("Why valid?")


    Sign time is: 
    Mon, 24 Aug 2020 04:05:40 UTC
    Expiry time is: 
    Mon, 24 Aug 2020 04:05:42 UTC
    First validation time is: 
    Mon, 24 Aug 2020 04:05:40 UTC
    Waiting for time to get Expiry limit
    OK lets parse and check again
    Second invalid validation time is: 
    Mon, 24 Aug 2020 04:05:44 UTC
    Why valid?
    opened by mhf-ir 1
  • TestOpaqueKeyRoundtripJWE is very slow, times out on slow platforms

    TestOpaqueKeyRoundtripJWE is very slow, times out on slow platforms


    We're seeing persistent timeouts testing new versions of this package on armhf in Ubuntu:

    There are a few slow tests but TestOpaqueKeyRoundtripJWE appears to be the slowest. Does it make sense to skip this test when -short is passed or something?

    Cheers, mwh

    opened by mwhudson 1
  • v2.6.0(Jun 5, 2021)

    Last release from the v2 branch, includes various changes and bug fixes.

    For future releases please see v3 at:

    Source code(tar.gz)
    Source code(zip)
  • v2.5.1(Apr 30, 2020)

  • v2.5.0(Apr 12, 2020)

    New Features

    • Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).
    • Add support for RFC 7638 canonical kid for JWK (#269).

    Bug Fixes

    • Add error checking in jose-util to avoid nil referencing (#250).
    • Documentation improvements (#274, #280, #289).
    Source code(tar.gz)
    Source code(zip)
  • v2.4.1(Dec 16, 2019)

    Bug Fixes

    • Fixes a bug introduced in v2.4.0 that could cause a panic on invalid inputs (#282).
    • Improves performance of parsing payloads with a lot of whitespace (#279).
    Source code(tar.gz)
    Source code(zip)
  • v2.4.0(Oct 23, 2019)

    New Features

    • Add support for the b64 header parameter (#230).
    • Add functions to handle detached signatures (#234).
    • Expose an interface for opaque key encryption/decryption (#261, #257).

    Bug Fixes

    • Fixes a issue with ECDSA on P-521, whereby the generated shared secret derived for encryption was computed incorrectly (#267, #245).
    • Fixes salt length for new RSA-PSS messages to be equal to the hash length, as required by RFC 3447 (#232).
    • Don't include the kid header in a JWT if the key id is an empty string (#227).
    Source code(tar.gz)
    Source code(zip)
  • v2.3.1(Apr 10, 2019)

    Fixes a bug in the serialization of ED25519 keys to JWK (JSON), where X/D values ended up being switched for one another in the serialized output (see #224). Reading a serialized private key would also end up switching the X/D values for another, so keys that were serialized/deserialized with old versions of go-jose would work fine (values should end up in the correct place again). However, sharing a private key with another library would have caused problems. If you have private keys that were previously serialized to JWK using this library, the X/D values will be incorrect and will need to be switched in the JSON serialization before the key can be deserialized with an updated version of go-jose.

    Source code(tar.gz)
    Source code(zip)
  • v2.3.0(Feb 26, 2019)

    New Features

    • Add support for unwrapping JSON Web Key Set in the jwt sub-package. This means the key passed to Claims or Decrypt can now be a set of keys (of type *jose.JSONWebKeySet), and the key will be selected automatically based on the key id in the header of the token.

    Bug Fixes

    • Improves handling of exp, iat and nbf claims. This means proper handling for zero dates (#214), don't error if optional exp and nbf claims are missing from the token (#220), and perform an extra check on iat if it is present (#217). Note that expiration in tokens is optional per standard, if you want to require expiration or other claims to be absolutely present in a token be sure to check the claim is present.

    Note this release also drops support for Go 1.5 and Go 1.6, we now require Go 1.7 or later.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.2(Jan 2, 2019)

    Exports the random reader used for internal randomness to make deterministic tests possible (#212). This allows consumers of the library to add tests that can compare known inputs/outputs deterministically.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.1(Dec 5, 2018)

    This release adds stricter checks (#210) for handling JWKs with elliptic keys. As per RFC 7518, Section to the length of this octet strings for X/Y/D values in JWKs MUST be the full size of a coordinate for the curve specified in the "crv" parameter. As a result, invalid JWKs that were previously accepted (e.g. a JWK where the padding was missing on X/Y coordinates) will now be rejected when parsing them.

    Source code(tar.gz)
    Source code(zip)
  • v2.2.0(Nov 29, 2018)

    Bug Fixes

    • Check that key size when matches cipher for DIRECT encryption mode (issue #204, fix in #205)
    • Fix auth tag length for A192CBC-HS384, A256CBC-HS512 to match spec (issue #206, fix in #207)

    Note: We bumped the minor version in this release because the changes in #207 fixes a compatibility issue with the implementations of the A192CBC-HS384 and A256CBC-HS512 ciphers. The library didn't correctly follow the JOSE specification (RFC 7518) when encrypting and as a result ciphertexts produced with square/go-jose were incompatible with other JOSE implementations. Ciphertexts produced from other libraries with those ciphers would still decrypt correctly. If you were encrypting with A192CBC-HS384 and A256CBC-HS512 using old versions of this library there might be compatibility concerns when upgrading.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.9(Sep 23, 2018)

    This release contains a small change to emit pre-computed values on RSA keys when serializing to a JWK, see pull request #203. This fixes issue #202.

    Source code(tar.gz)
    Source code(zip)
  • v2.1.8(Aug 8, 2018)

  • v2.1.7(Jul 25, 2018)

    New Features

    • Added new cryptosigner sub-package to sign using crypto.Signer implementations (#179).
    • Added new OpaqueSigner (et al) interfaces for implementing custom, opaque signers (#179).

    This release also contains several minor bug fixes and makes unit tests pass in Go 1.11.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.2(Jul 25, 2018)

  • v2.1.6(Mar 28, 2018)

    This release adds support for parsing certificate chains from x5c headers in messages, and expose a function to verify & read them through a new jose.Header#Certificates(opts x509.VerifyOptions) function (see #178).

    Source code(tar.gz)
    Source code(zip)
  • v2.1.5(Mar 23, 2018)

    This release adds DetachedVerify and DetachedVerifyMulti methods on JSONWebSignature to verify detached signatures, i.e. JWS objects where the payload has been stripped and is handled separately from the signature (#175).

    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Mar 22, 2018)

    Fixes a build issue with Go 1.10 and updates an incorrect error message. This makes the v1 branch compatible with the latest version of Go, but if you haven't already you should probably update to the v2 branch!

    Source code(tar.gz)
    Source code(zip)
  • v2.1.4(Feb 27, 2018)

    Notable changes

    • Fix build issue with Go 1.10 (#173)
    • Use consistent types for ed25519 keys (#165)
    • Added JSONWebKey.Public() to derive public key from private key (#166)
    • Added jwk-keygen tool contributed by @darkk (#166)
    • Expose protected/unprotected headers separately (#164)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.3(Sep 13, 2017)

    Notable changes

    • Add basic support for ED25519 signing via (issue #68, PR #154)
    • Fix panic when creating signer with JWK and setting EmbedJWK to true (issue #157, PR #161)
    • Fix an issue that would cause a panic when encountering null values in headers (PR #159)
    Source code(tar.gz)
    Source code(zip)
  • v2.1.2(Jun 7, 2017)

  • v2.1.1(May 3, 2017)

  • v2.1.0(Feb 24, 2017)

    Notable changes Support for custom/extra header values (#136) thanks to @hlandau. This is a slight change to the v2 interface, so the minor version has been bumped. Also includes a bug fix for symmetric keys to produce JWS objects (#139) thanks to @b1v1r.

    Source code(tar.gz)
    Source code(zip)
  • v2.0.1(Nov 21, 2016)

    Notable changes Support for nested (encrypted and signed) tokens in jwt package (#125) Support for non-pointer JSONWebKey in base package (#124)

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Oct 28, 2016)

    Cleaner interface The API for the base package has been reworked. In particular, encrypter/signer/decrypter/verifier objects are now immutable. An options struct can be passed to set various options when creating the object now. This is a bit more flexible and should make it easier to add new things in the future.

    Support for JWT Thanks to @shaxbee, go-jose now includes a new jwt sub-package with functions for dealing with encrypted/signed JWTs. See the documentation for the jwt package for more information.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Sep 22, 2016)

    Fixes and improvements

    • Add new VerifyMulti function to verify multi-signature JWS objects. The existing Verify function has been changed to only accept single-signature objects. This ensures that callers do not accidentally accept multi-signature objects in contexts where they are not expected (#111, 2c5656a).
    • Add new DecryptMulti function to decrypt multi-recipient JWE messages. The existing Decrypt function has been changed to only accept single-recipient messages. This ensures callers do not accidentally accept multi-recipient messages in contexts where they are not expected (#111, 2c5656a).
    • Add checks when deserializing JWS objects to ensure that any embedded JWK (if present) is valid and represents a public key (not private/symmetric key) as per spec. This is to ensure that callers don't accidentally end up accepting embedded JWKs that represent symmetric/private keys (#112, e8e21a9).

    Note that this represents a subtle API change, as the Decrypt and Verify functions are now stricter than before and only accept single-signature/single-recipient inputs. To reflect this change, the minor version has been bumped.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.5(Sep 3, 2016)

    Security fixes Cast all size calculations to uint64 to avoid int overflows on 32-bit architectures (789a4c4)

    Other changes Proper import paths on v1 branch to fix build (3bd67f4)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.4(Aug 31, 2016)

    Security fixes For ECDH-ES key derivation (in JWE), ensure that received public key (from an "epk" header field on an encrypted message) is on expected elliptic curve before performing any cryptographic operations. This also adds various sanity checks for EC keys other places, e.g. when parsing JWK blobs with embedded EC keys. See commits c758193, 03c5c6e, d163d44.

    Other changes Fix expand command in jose-util (c18180c) Remove support for std_json build tag (1f36a88)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.3(Aug 8, 2016)

  • v1.0.2(May 2, 2016)

    Notable changes Switch jose-util to use alecthomas/kingpin for flag parsing (15af859) Add JsonWebKey.Valid method to check key validity (h/t @rolandshoemaker, d2a8471)

    Source code(tar.gz)
    Source code(zip)
  • v1.0.1(Apr 19, 2016)

An implementation of JOSE standards (JWE, JWS, JWT) in Go

Go JOSE Package jose aims to provide an implementation of the Javascript Object Signing and Encryption set of standards. This includes support for JSO

Square 1.8k Jul 23, 2021
This package provides json web token (jwt) middleware for goLang http servers

jwt-auth jwt auth middleware in goLang. If you're interested in using sessions, checkout my sessions library! README Contents: Quickstart Performance

Adam Hanna 204 Jul 23, 2021
The easiest JWT library to GO

JWT Go The easiest JWT Library that could be a starting point for your project. Installation go get Quick Start package ma

Supan Adit Pratama 16 Apr 21, 2021
A go implementation of JSON Web Tokens

jwt-go A go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens NEW VERSION COMING: There have been a lot of improvements s

null 462 Aug 2, 2021
JWT login microservice with plugable backends such as OAuth2, Google, Github, htpasswd, osiam, ..

loginsrv loginsrv is a standalone minimalistic login server providing a JWT login for multiple login backends. ** Attention: Update to v1.3.0 for Goog

tarent 1.8k Jul 23, 2021
Golang implementation of JSON Web Tokens (JWT)

jwt-go A go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens NEW VERSION COMING: There have been a lot of improvements s

Dave Grijalva 9.8k Jul 25, 2021
Safe, simple and fast JSON Web Tokens for Go

jwt JSON Web Token for Go RFC 7519, also see for more. The latest version is v3. Rationale There are many JWT libraries, but many of them are h

cristaltech 281 Jul 19, 2021
JSON Web Token library

About … a JSON Web Token (JWT) library for the Go programming language. Feature complete Full test coverage Dependency free Key management The API enf

Pascal S. de Kloe 259 Jul 30, 2021
Platform-Agnostic Security Tokens implementation in GO (Golang)

Golang implementation of PASETO: Platform-Agnostic Security Tokens This is a 100% compatible pure Go (Golang) implementation of PASETO tokens. PASETO

Oleg Lobanov 524 Jul 18, 2021
simple-jwt-provider - Simple and lightweight provider which exhibits JWTs, supports login, password-reset (via mail) and user management.

Simple and lightweight JWT-Provider written in go (golang). It exhibits JWT for the in postgres persisted user, which can be managed via api. Also, a password-reset flow via mail verification is available. User specific custom-claims also available for jwt-generation and mail rendering.

Max 19 Jul 28, 2021
This is an implementation of JWT in golang!

jwt This is a minimal implementation of JWT designed with simplicity in mind. What is JWT? Jwt is a signed JSON object used for claims based authentic

John Rowley 90 Jun 13, 2021
Simple JWT Golang

sjwt Simple JSON Web Token - Uses HMAC SHA-256 Example // Set Claims claims := New() claims.Set("username", "billymister") claims.Set("account_id", 86

Brian Voelker 92 Jul 4, 2021
Golang Mongodb Jwt Auth Example Using Echo

Golang Mongodb Jwt Auth Example Using Echo Golang Mongodb Rest Api Example Using Echo Prerequisites Golang 1.16.x Docker 19.03+ Docker Compose 1.25+ I

Şuayb Şimşek 5 Jun 24, 2021
an SSO and OAuth / OIDC login solution for Nginx using the auth_request module

Vouch Proxy An SSO solution for Nginx using the auth_request module. Vouch Proxy can protect all of your websites at once. Vouch Proxy supports many O

Vouch 1.4k Jul 31, 2021