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
  • 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
  • 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
  • Version 2.5.0: has breaking changes in terms of certificate verfication

    Version 2.5.0: has breaking changes in terms of certificate verfication


    -Add support for x5u, x5t, and x5t#S256 headers for JWK (#242).

    #issue 1 has some breaking changes particularly in the jwk.go, where

    method name : func (k *JSONWebKey) UnmarshalJSON(data []byte) (err error)

    k.CertificateThumbprintSHA1 = raw.X5tSHA1.bytes() k.CertificateThumbprintSHA256 = raw.X5tSHA256.bytes()

    here the raw value is attempted to convert in bytes but it does not work as expected in fact, it returns base64 decoded value for kid attribute in the token.

    as a result following conditions always fails,

    if x5tSHA1Len > 0 && x5tSHA1Len != sha1.Size { return errors.New("square/go-jose: invalid JWK, x5t header is of incorrect size") } if x5tSHA256Len > 0 && x5tSHA256Len != sha256.Size { return errors.New("square/go-jose: invalid JWK, x5t header is of incorrect size") }

    here sha1.Size is the checksum size which is expected to be 20 bytes. but the value which we are assigning k.CertificateThumbprintSHA1 is not a checksum instead it's a raw hash for sha1 or sha256. So when x5tSHA1Len := len(k.CertificateThumbprintSHA1))is executed length turns out to be 40

    solutions: use x5tSHA1Len := len(sha1.Sum(k.CertificateThumbprintSHA1))

    #issue 2

    // If certificate chain and thumbprints are set, verify correctness. if len(k.Certificates) > 0 { leaf := k.Certificates[0] sha1sum := sha1.Sum(leaf.Raw) sha256sum := sha256.Sum256(leaf.Raw) if len(k.CertificateThumbprintSHA1) > 0 && !bytes.Equal(sha1sum[:], k.CertificateThumbprintSHA1) { return errors.New("square/go-jose: invalid JWK, x5c thumbprint does not match x5t value") }

    	if len(k.CertificateThumbprintSHA256) > 0 && !bytes.Equal(sha256sum[:], k.CertificateThumbprintSHA256) {
    		return errors.New("square/go-jose: invalid JWK, x5c thumbprint does not match x5t#S256 value")

    I don't understand what are we trying to validate here but this condition seems to be failing always.

    feel free to reach out in case of questions or queries

    opened by hiten1988 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
  • 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
  • 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
  • Regenerate X.509 cert with SAN extension (v2)

    Regenerate X.509 cert with SAN extension (v2)

    The certificate for CN=TrustedSigner has been regenerated with SAN extension. Due to missing keys, certs for CN=TrustedCA & CN=IntermediateCA have been regenerated as well.

    Resolves #330.

    opened by pippo 9
  • Fix JWK Thumbprint/kid for Ed25519 keys

    Fix JWK Thumbprint/kid for Ed25519 keys

    The format string edThumbprintTemplate was broken, missing opening " before x property name. It cause interoperability issues with other JOSE implementations.

    opened by szkiba 8
  • Add fallback to std URLEncoding for JWKs

    Add fallback to std URLEncoding for JWKs

    In case RawURLEndocing fails while decoing JWKs, try if falling back to Standard URLEncoding can decode - which may be the case i.e with padded JWKs

    Fixes #373

    opened by oxygen0211 4
  • x5t and x5t#S256 headers with padding breaking key unmarshalling

    x5t and x5t#S256 headers with padding breaking key unmarshalling

    Hi everyone,

    I am using go-jose as a transient dependency (in oauth2-proxy) at a customer's in combination with Oracle Access Manager. Since the release of 2.5.1 (I guess due to the fix of #299 ), validation of the JWK in use is breaking with the error message square/go-jose: invalid JWK, x5t header has invalid encoding.

    I think I narrowed the issue down to Base64 padding of the x5t and x5t#S256 headers breaking the decoding of the headers in and respectively for x5t#S256.

    For compliance reasons, I am not able to submit the real key for testing but I was able to construct a test key based on that is triggering the same behavior:

          "kty": "RSA",
          "e": "AQAB",
          "x5t": "wCAFGcBT8CeA4U2mYa4z3xg0-Zw=",
          "kid": "SIGNING_KEY",
          "x5c": [
          "alg": "RS256",
          "n": "xWVFlx-E925RYQjPnKpKtHLqUonJMI1_xyM1f4Orly9RzpcaXX7ajEkgMAzffL3rsvBQkPLmO0vHIHs4KNdWoVUmbLZerjDdfLZQl3FZuXcZKXtzVOLyBVt2SNp_k23VgyGN7-8tiAJWC9SFIPBdWD8U2dxqM9izSEn9pvoMyR5iyaEoZepazJQPLysrF23g1_gI8Bo2EUAHdO5atfGfT2YQbZPSOBWiq09QYwMRBuI0Ye0TI3GwYs1x3_2LoporOj-fkYCl4ki4JK2ifwk-TA5o29cdNSuSoA7rTZL3u-dNw0c6OPxvnW6LtCn4RpieZTh7W2sYLg8ozBwd3PHNTw"

    Unfortunately, this one does not have a SHA 256 fingerprint, though.

    My propose on handling this would be to fall back to decoding with base64.URLEncoding in case base64.RawURLEncoding is failing:

    // x5t parameters are base64url-encoded SHA thumbprints
    // See RFC 7517, Section 4.8,
    x5tSHA1bytes, err := base64.RawURLEncoding.DecodeString(raw.X5tSHA1)
    // we might get base64 encoded parameters that include padding
    // this is not supported by RawURLEncoding, so as a backup, let's try to decode with URL encoding
    if err != nil {
    	x5tSHA1bytes, err = base64.URLEncoding.DecodeString(raw.X5tSHA1)
    if err != nil {
    	return errors.New("square/go-jose: invalid JWK, x5t header has invalid encoding")

    However, I am not a Go expert, so please correct me if there is a better way. Currently I am checking if I can submit a proper PR for this without breaking compliance.

    opened by oxygen0211 0
  • Unencoded Payload Option WithBase64 still encodes payload to base64 through MarshalJSON?

    Unencoded Payload Option WithBase64 still encodes payload to base64 through MarshalJSON?

    As far as I understand, go-jose implements the JSON Web Signature (JWS) Unencoded Payload Option ( via the SigningOption: func (*SignerOptions) WithBase64.

    I tried setting this option via: opt := (&jose.SignerOptions{}).WithBase64(false), but it still leads to a base64 encoded payload when using full serialization. The option is indeed evaluated and the payload is not base64 encoded in signing.go (, but then, in the FullSerialize() the rawJSONWebSignature containing a Payload *byteBuffer is serialized.

    For the byteBuffer, a custom JSON Marshalling method is implemented in encoding.go ( and this method always encodes base64:

    func (b *byteBuffer) MarshalJSON() ([]byte, error) {
    	return json.Marshal(b.base64())

    Did I do something wrong using the WithBase64() option or doesn't this mean setting WithBase64 still leads to base64-encoded payload?

    opened by smo4201 0
  • AutoRefreshing JWK ?

    AutoRefreshing JWK ?

    Does this project have helper methods or something for a jwk that fetch keys from a remote url ? something like below

           const url = ""
    	jwks, err := NewJWKFromWeb(url)
    	key, err := jwks.Key("id1")
    opened by asanka88 1
  • square/go-jose: error in cryptographic primitive

    square/go-jose: error in cryptographic primitive

    I have a decryption key and a JWE token that I can decrypt in python like so:

    from jose import jwe, jwt
    from jose.utils import base64url_decode
    decryption_key_bytes = base64url_decode("ODFfdsdfs879s8fs=")
    decrypted_token = jwe.decrypt(TOKEN, decryption_key_bytes)
    print("Decrypted token:")
    print("\nToken contents:")
    print(jwt.decode(decrypted_token, None, options={"verify_signature": False}))

    Doing the "same" In golang results in the above error:

    package main
    import (
    const customersJweRaw = "sfsdfsdfsfs.sfsfsdfsf.sfsfsfsf"
    func main() {
    	base64Decode, err := base64.StdEncoding.DecodeString("ODFfdsdfs879s8fs=")
    	if err != nil {
    	jwe, err1 := jose.ParseEncrypted(customersJweRaw)
    	if err1 != nil {
    	bytes, err2 := jwe.Decrypt(jose.JSONWebKey{Algorithm: "A256KW", Use: "A256GCM", Key: base64Decode})
    	if err2 != nil {

    I have also tried not specifying the encryption / decryption algorithm and just pass the key like so: jwe.Decrypt(base64Decode), but got the same result.

    Bellow is the screenshot of the document for the token origin. I am not creator of the token, we get it from the client.

    Screen Shot 2022-01-25 at 12 24 45 PM
    opened by apryiomka 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(May 1, 2020)

  • v2.5.0(Apr 13, 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 27, 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 30, 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 29, 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 23, 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 28, 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 25, 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 23, 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 20, 2016)

Go-gin-jwt - Secure web api using jwt token and caching mechanism

Project Description This project demonstrate how to create api and secure it wit

Jeremy Panjaitan 0 Jan 27, 2022
JWT wrapper library which makes it simple to use ECDSA based JWT signing

JWT JWT wrapper library which makes it simple to user ECDSA based JWT signing. Usage package main import ( "context" "

infinite loop 0 Feb 10, 2022
Account-jwt-go - Simple JWT api with go, gorm, gin

Account JWT on Go Go, gorm, Gin web framework 를 활용하여 만든 간단한 JWT API 입니다. Dajngo의

Deagwon Bu 1 Apr 14, 2022
Krakend-jwt-header-rewriter - Kraken Plugin - JWT Header Rewriter

Kraken Plugin - JWT Header Rewriter 1 Plugin Configuration Name Desciption Defau

null 0 Feb 15, 2022
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 99 Oct 25, 2022
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 10.5k Nov 22, 2022
A fast and simple JWT implementation for Go

JWT Fast and simple JWT implementation written in Go. This package was designed with security, performance and simplicity in mind, it protects your to

Gerasimos (Makis) Maropoulos 153 Nov 26, 2022
backend implementation demonstration in go with JWT, MongoDB and etc.

backend implementation demonstration in go with JWT, MongoDB and etc.

Parham Alvani 12 Nov 9, 2022
Golang implementation of JWT and Refresh Token

Fiber and JWT with Refresh Token Repo ini adalah demostrasi JWT support refresh token tanpa menggunakan storage Branch Main: unlimited refresh token R

Muhamad Surya Iksanudin 19 Sep 29, 2022
:key: Secure alternative to JWT. Authenticated Encrypted API Tokens for Go.

branca branca is a secure alternative to JWT, This implementation is written in pure Go (no cgo dependencies) and implements the branca token specific

Wesley Hill 166 Oct 21, 2022
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 223 Oct 29, 2022
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.9k Nov 19, 2022
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 106 Nov 10, 2022
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 30 Oct 12, 2022
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 14 Sep 23, 2022
YSHOP-GO基于当前流行技术组合的前后端RBAC管理系统:Go1.15.x+Beego2.x+Jwt+Redis+Mysql8+Vue 的前后端分离系统,权限控制采用 RBAC,支持数据字典与数据权限管理,支持动态路由等

YSHOP-GO 后台管理系统 项目简介 YSHOP-GO基于当前流行技术组合的前后端RBAC管理系统:Go1.15.x+Beego2.x+Jwt+Redis+Mysql8+Vue 的前后端分离系统,权限控制采用 RBAC,支持数据字典与数据权限管理,支持动态路由等 体验地址: https://go

null 127 Nov 23, 2022
Small Lambda function which performs a Aws:Sts:AssumeRole based on the presented JWT-Token

About This implements a AWS Lambda handler which takes a JWT-Token, validates it and then performs a Aws:Sts:AssumeRole based on preconfigured rules.

AOE 5 Aug 8, 2022
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 6 Nov 1, 2022
jwt package for gin go applications

gin-jwt jwt package for gin go applications Usage Download using go module: go get Import it in your code: import gwt "gith

Igor Volkov 2 Apr 21, 2022