A go implementation of JSON Web Tokens



build Go Reference

A go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens

NEW VERSION COMING: There have been a lot of improvements suggested since the version 3.0.0 released in 2016. I'm working now on cutting two different releases: 3.2.0 will contain any non-breaking changes or enhancements. 4.0.0 will follow shortly which will include breaking changes. See the 4.0.0 milestone to get an idea of what's coming. If you have other ideas, or would like to participate in 4.0.0, now's the time. If you depend on this library and don't want to be interrupted, I recommend you use your dependency mangement tool to pin to version 3.

SECURITY NOTICE: Some older versions of Go have a security issue in the crypto/elliptic. Recommendation is to upgrade to at least 1.8.3. See issue #216 for more detail.

SECURITY NOTICE: It's important that you validate the alg presented is what you expect. This library attempts to make it easy to do the right thing by requiring key types match the expected alg, but you should take the extra step to verify it in your usage. See the examples provided.

What the heck is a JWT?

JWT.io has a great introduction to JSON Web Tokens.

In short, it's a signed JSON object that does something useful (for example, authentication). It's commonly used for Bearer tokens in Oauth 2. A token is made of three parts, separated by .'s. The first two parts are JSON objects, that have been base64url encoded. The last part is the signature, encoded the same way.

The first part is called the header. It contains the necessary information for verifying the last part, the signature. For example, which encryption method was used for signing and what key was used.

The part in the middle is the interesting bit. It's called the Claims and contains the actual stuff you care about. Refer to RFC 7519 for information about reserved keys and the proper way to add your own.

What's in the box?

This library supports the parsing and verification as well as the generation and signing of JWTs. Current supported signing algorithms are HMAC SHA, RSA, RSA-PSS, and ECDSA, though hooks are present for adding your own.


See the project documentation for examples of usage:


This library publishes all the necessary components for adding your own signing methods. Simply implement the SigningMethod interface and register a factory method using RegisterSigningMethod.

Here's an example of an extension that integrates with multiple Google Cloud Platform signing tools (AppEngine, IAM API, Cloud KMS): https://github.com/someone1/gcp-jwt-go


This library was last reviewed to comply with RTF 7519 dated May 2015 with a few notable differences:

  • In order to protect against accidental use of Unsecured JWTs, tokens using alg=none will only be accepted if the constant jwt.UnsafeAllowNoneSignatureType is provided as the key.

Project Status & Versioning

This library is considered production ready. Feedback and feature requests are appreciated. The API should be considered stable. There should be very few backwards-incompatible changes outside of major version updates (and only with good reason).

This project uses Semantic Versioning 2.0.0. Accepted pull requests will land on main. Periodically, versions will be tagged from main. You can find all the releases on the project releases page.

While we try to make it obvious when we make breaking changes, there isn't a great mechanism for pushing announcements out to users. You may want to use this alternative package include: gopkg.in/golang-jwt/jwt.v3. It will do the right thing WRT semantic versioning.


  • Version 3.0.0 includes a lot of changes from the 2.x line, including a few that break the API. We've tried to break as few things as possible, so there should just be a few type signature changes. A full list of breaking changes is available in VERSION_HISTORY.md. See MIGRATION_GUIDE.md for more information on updating your code.

Usage Tips

Signing vs Encryption

A token is simply a JSON object that is signed by its author. this tells you exactly two things about the data:

  • The author of the token was in the possession of the signing secret
  • The data has not been modified since it was signed

It's important to know that JWT does not provide encryption, which means anyone who has access to the token can read its contents. If you need to protect (encrypt) the data, there is a companion spec, JWE, that provides this functionality. JWE is currently outside the scope of this library.

Choosing a Signing Method

There are several signing methods available, and you should probably take the time to learn about the various options before choosing one. The principal design decision is most likely going to be symmetric vs asymmetric.

Symmetric signing methods, such as HSA, use only a single secret. This is probably the simplest signing method to use since any []byte can be used as a valid secret. They are also slightly computationally faster to use, though this rarely is enough to matter. Symmetric signing methods work the best when both producers and consumers of tokens are trusted, or even the same system. Since the same secret is used to both sign and validate tokens, you can't easily distribute the key for validation.

Asymmetric signing methods, such as RSA, use different keys for signing and verifying tokens. This makes it possible to produce tokens with a private key, and allow any consumer to access the public key for verification.

Signing Methods and Key Types

Each signing method expects a different object type for its signing keys. See the package documentation for details. Here are the most common ones:

  • The HMAC signing method (HS256,HS384,HS512) expect []byte values for signing and validation
  • The RSA signing method (RS256,RS384,RS512) expect *rsa.PrivateKey for signing and *rsa.PublicKey for validation
  • The ECDSA signing method (ES256,ES384,ES512) expect *ecdsa.PrivateKey for signing and *ecdsa.PublicKey for validation

JWT and OAuth

It's worth mentioning that OAuth and JWT are not the same thing. A JWT token is simply a signed JSON object. It can be used anywhere such a thing is useful. There is some confusion, though, as JWT is the most common type of bearer token used in OAuth2 authentication.

Without going too far down the rabbit hole, here's a description of the interaction of these technologies:

  • OAuth is a protocol for allowing an identity provider to be separate from the service a user is logging in to. For example, whenever you use Facebook to log into a different service (Yelp, Spotify, etc), you are using OAuth.
  • OAuth defines several options for passing around authentication data. One popular method is called a "bearer token". A bearer token is simply a string that should only be held by an authenticated user. Thus, simply presenting this token proves your identity. You can probably derive from here why a JWT might make a good bearer token.
  • Because bearer tokens are used for authentication, it's important they're kept secret. This is why transactions that use bearer tokens typically happen over SSL.


This library uses descriptive error messages whenever possible. If you are not getting the expected result, have a look at the errors. The most common place people get stuck is providing the correct type of key to the parser. See the above section on signing methods and key types.


Documentation can be found on pkg.go.dev.

The command line utility included in this project (cmd/jwt) provides a straightforward example of token creation and parsing as well as a useful tool for debugging your own integration. You'll also find several implementation examples in the documentation.

  • Backwards-compatible implementation of RFC7519's registered claim's structure

    Backwards-compatible implementation of RFC7519's registered claim's structure

    This PR aims at implementing compliance to RFC7519, as documented in #11 without breaking the public API. It creates a new struct RegisteredClaims and deprecates (but not removes) the StandardClaims. It introduces a new type NumericDate, which represents a JSON numeric date value as specified in the RFC. This allows us to handle float as well as int-based time fields in aud, exp and nbf. Additionally, it introduces the type StringArray, which is basically a wrapper around []string to deal with the oddities of the JWT aud field.

    Closes #11

    opened by oxisto 29
  • Address cached references to old versions in the Go module proxy

    Address cached references to old versions in the Go module proxy

    Unfortunately the Go module proxy (i.e., mirror) cached 2 versions:


    When a user does a go get github.com/golang-jwt/jwt it will download the following version:

    github.com/golang-jwt/jwt v3.2.0+incompatible // indirect

    Whereas it should import the correct one (based on latest commit on main)

    github.com/golang-jwt/jwt v0.0.0-20210529012641-6a07921e6808 // indirect

    If we cannot get those 2 versions removed from the proxy, we'll have to go with plan B... add a /v3 and tag a v3.2.1

    opened by mfridman 17
  • Placeholder repo migrating maintenance

    Placeholder repo migrating maintenance

    See https://github.com/dgrijalva/jwt-go/issues/462 for a lengthier discussion and background.

    For brevity, there is/was an attempt to migrate to the gors organization, issues here, but unfortunately there was no response on GitHub issue or Slack #gofrs channel.

    Hopefully other can chip in, but afaics the goal of this org/repo:

    1. patch any outstanding security issues
    2. add module support
    3. maintain the existing jwt-go API in its current form
    4. setup GitHub Actions as CI for existing tests
    5. have a few independent maintainers to spread the load and trust of maintenance with the ultimate goal of the Go community having access to a stable JWT package.

    The intention is to support the package in its current form without any major re-write or refactor.

    I still hope one day the Go standard library or /x will add JWT support and backing from the Go team.

    If there is agreement we can setup independent GitHub issues to tackle the above and address these in particular.

    https://github.com/dgrijalva/jwt-go/issues/428 https://github.com/dgrijalva/jwt-go/issues/463

    cc @ripienaar @Waterdrips @lggomez

    opened by mfridman 17
  • Due to the use of fillBytes golang-jwt now requires go1.15

    Due to the use of fillBytes golang-jwt now requires go1.15


    from #33, means that golang-jwt/jwt now requires go1.15.

    Is this intentional?

    opened by zeripath 12
  • Adds go module support /v4

    Adds go module support /v4

    Introduces modules support with with/v4 SIV

    • [x] Update migration guide
    • [x] Update README to ensure import paths are correct referenced

    fixes #5 #3 #30

    opened by mfridman 12
  • Revert Encoding/Decoding changes for better compatibility

    Revert Encoding/Decoding changes for better compatibility

    This is a small revert to the optimizations made to the encoding/decoding in https://github.com/golang-jwt/jwt/pull/33.

    While technically JWTs should not have padded characters in Base64 URL encoding, it seems like not every provider may follow this construct, specifically AWS Cognito as seen in https://github.com/golang-jwt/jwt/issues/92.

    While the change initially was made to have better optimization, it has left compatibility issues, forcing dependencies to stay on v3.2.1 until an update occurs. Thus the proposal is to simply undo the changes made in that section of code, and create a new ticket to better optimize this section.

    opened by ajermaky 10
  • upstream fix for security vulnerability from form3tech-oss/jwt-go fork

    upstream fix for security vulnerability from form3tech-oss/jwt-go fork

    This forwards the changes of https://github.com/form3tech-oss/jwt-go/pull/14 to the upstream repository.

    I am not the author of the original PR (nor do I know much about JWT), but thought I'd give this an attempt, following the discussion in https://github.com/Azure/go-autorest/issues/642 (and issues linked from there).

    Fixes a security vulnerability where a jwt token could potentially be validated having invalid string characters.

    (cherry picked from commit a211650c6ae1cff6d7347d3e24070d65dcfb1122) https://github.com/form3tech-oss/jwt-go/pull/14

    opened by thaJeztah 10
  • Add go module support

    Add go module support

    The existing project https://github.com/dgrijalva/jwt-go had no module support and was likely imported as:

    github.com/dgrijalva/jwt-go v3.2.0+incompatible

    There was also a v4 that never got fully released.

    go get github.com/dgrijalva/[email protected]
    go get: github.com/dgrijalva/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

    Since users would import a new module anyways, one solution could be drop all existing versions (14 total) and start with a fresh v1.0.0 (hopefully no breaking changes required).

    For many of my projects I see this being a basic search/replace operation:

    - github.com/dgrijalva/jwt-go v3.2.0+incompatible
    + github.com/golang-jwt/jwt v1.0.0

    The version in this case is irrelevant afaics.

    Lastly, I am not sure whether the original repo will get "transferred" or "archived" (see comment here), but if it gets transferred then this might change the outcome of how to proceed adding module support?

    Thoughts, suggestions welcome.

    opened by mfridman 10
  • v4.4.0 breaks backwards compatibilty

    v4.4.0 breaks backwards compatibilty

    After upgrading from 4.3.0 to 4.4.0, my custom implementation of the Claims interface is broken:

    	*Claims does not implement jwt.Claims (wrong type for Valid method)
    		have Valid() error
    		want Valid(opts ...jwt.validationOption) error
    opened by dim 9
  • Handling malformed JWT (includes padding)

    Handling malformed JWT (includes padding)

    I'm trying to integrate with Amazon Cognito behind an AWS load balancer. Cognito supplies a JWT, but the token includes padding. Yes, this makes it a malformed token, but it's not a token which I can change. (Specifically, when running behind an Application Load Balancer, I need to validate the x-amzn-oidc-data header. Infuriatingly, they also provide a second JWT, which is not malformed, but doesn't include some specific details which I need...)

    v3.2.2 included PR#33, which changes how the library handles this situation. Prior to the change, the Base64 text was correctly parsed, as the decoded expected padding (and this was added if it was missing). Now, the base64 parser returns an error ("illegal base64 data").

    Stripping the padding before passing to the library allows the base64 deserialisation to succeed, but the signature then fails to validate.

    Currently my only option (other than looking for a different library) seems to be to stick to v3.2.1... Any other suggestions would be very welcome!

    opened by is-alnilam 9
  • When exp indicates the present, make it invalid.

    When exp indicates the present, make it invalid.


    The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

    it is written on the reference. So, it seems invalid when exp indicates the present. Isn't it right?

    opened by soranoba 9
  • How to handle multiple claim types

    How to handle multiple claim types


    I might have a a case which is kind of special but maybe there is anyone who has an idea.

    I use this great package to issue two types of JWTs:

    • One is for actual human users. These tokens use a type UserClaims struct which embeds the standard claims type. Claims are email, firstName, lastName and similar.
    • The other one is for bots. These use type BotClaims struct which also embeds the standard claims type but does not require the claims used for human users. Instead they have some special claims like botId and botType.

    I can't really figure out how to use jwt.Parse or jwt.ParseWithClaims to allow usage of both claim types.

    The only idea I have is using MapClaims but then I'd lose the benefit of having explicit types for the two claim types.

    Has anyone experience with this? Sincerely.

    opened by FabianTe 0
  • Fixed integer overflow in NumericDate.MarshalJSON

    Fixed integer overflow in NumericDate.MarshalJSON

    Fixed #199

    The original issue was caused by the fact that if we use a very large unix timestamp. The resulting value from Time.UnixNano() overflows a int64, as documented here: https://pkg.go.dev/time#Time.UnixNano.

    This patch works around the issue by treating the second part and nanosecond part separately, taking the second part from Time.Unix(), and the nanosecond part from Time.Nanosecond(), formatting them separately, and then combining the resulting strings.

    This approach allows us to correctly marshal all go time.Time instances, whereas using Time.Unix won't give us enough precision, and either Time.UnixMicro or Time.UnixNano would overflow at some point for even valid time.Time instances.

    The added benefit of this approach is that we no longer have to deal with the added nanosecond delta that Go uses in order to achieve monotonic time, so the result of marshaling time.Unix(0, 123456) will simply be 0.123456 instead of 0.123456 + small_delta.

    opened by qqiao 0
  • NumericDate.MarshalJSON overflows on large unix timestamps

    NumericDate.MarshalJSON overflows on large unix timestamps

    Marshalling NewNumericDate(time.Unix(253402271999, 0)) will result in -4852145033 instead of 253402271999

    Updates: This is due to the fact that Time.UnixNano() overflows, and NumericDate.MarshalJSON() internally uses this method.

    PR #200 created to workaround this std library limitation.

    opened by qqiao 6
  • Add package installation guidelines to README.md

    Add package installation guidelines to README.md

    Hey, I'd like to add the package's installation guidelines to the README file. This would make it easier for the users to install the package in their projects by simply copying and pasting the command to their terminals.

    Could this issue be assigned to me?

    Let me know what you think of the above.

    opened by morelmiles 4
  • key is of invalid type for

    key is of invalid type for "typ": "JWS"

    My JWT has a header like this:

      "typ": "JWS",
      "alg": "RS256",
      "kid": "9167337"

    Note this is is JWS not JWT.

    When I call jwt.Parse() on it like this, I get token.Valid is false:

    token, err := jwt.Parse(authToken, func(token *jwt.Token) (interface{}, error) {
            return []byte("AllYourBase"), nil

    The error is "key is of invalid type". Am I doing something wrong here, or is JWS unsupported?

    opened by mrichman 3
  • v4.4.1(Mar 26, 2022)

    What's Changed

    • Add go1.18 to ci pipeline by @mfridman in https://github.com/golang-jwt/jwt/pull/173
    • Revert "feat: port clockskew support (#139)" by @mfridman in https://github.com/golang-jwt/jwt/pull/184

    Note, this release contains a Go module retraction for a prior release v4.4.0:

    retract (
        v4.4.0 // Contains a backwards incompatible change to the Claims interface.

    Full Changelog: https://github.com/golang-jwt/jwt/compare/v4.4.0...v4.4.1

    Source code(tar.gz)
    Source code(zip)
  • v4.4.0(Mar 16, 2022)

    What's Changed

    • fix: expired token error message by @ydylla in https://github.com/golang-jwt/jwt/pull/165
    • feat: port clockskew support by @ksegun in https://github.com/golang-jwt/jwt/pull/139

    New Contributors

    • @ydylla made their first contribution in https://github.com/golang-jwt/jwt/pull/165
    • @ksegun made their first contribution in https://github.com/golang-jwt/jwt/pull/139

    Full Changelog: https://github.com/golang-jwt/jwt/compare/v4.3.0...v4.4.0

    Source code(tar.gz)
    Source code(zip)
  • v4.3.0(Feb 10, 2022)

    What's Changed

    • Support errors.Is for token extractors by @stefantds in https://github.com/golang-jwt/jwt/pull/141
    • Implementing Is(err) bool to support Go 1.13 style error checking by @oxisto in https://github.com/golang-jwt/jwt/pull/136
    • remove unnecessary for loop in token signing string for readability by @hyeonjae in https://github.com/golang-jwt/jwt/pull/34
    • updated README.md to contain more extensions by @matelang in https://github.com/golang-jwt/jwt/pull/155
    • Add JWT logo attribution by @mfridman in https://github.com/golang-jwt/jwt/pull/161
    • fix: fixed typo detect by cSpell by @giautm in https://github.com/golang-jwt/jwt/pull/164
    • Set json encoding precision by @mfridman in https://github.com/golang-jwt/jwt/pull/162

    New Contributors

    • @stefantds made their first contribution in https://github.com/golang-jwt/jwt/pull/141
    • @hyeonjae made their first contribution in https://github.com/golang-jwt/jwt/pull/34
    • @matelang made their first contribution in https://github.com/golang-jwt/jwt/pull/155
    • @giautm made their first contribution in https://github.com/golang-jwt/jwt/pull/164

    Full Changelog: https://github.com/golang-jwt/jwt/compare/v4.2.0...v4.3.0

    Source code(tar.gz)
    Source code(zip)
  • v4.2.0(Dec 3, 2021)

    • Fix the comment of VerifyExpiresAt (#109) @shogo82148
    • Introducing functional-style options for the Parser type (#108) @oxisto
    • Improve code comments, including security consideration (#107) @sebastien-rosset
    • Fix int64 overflow in newNumericDateFromSeconds (#112) @PiotrKozimor
    • Fixes jwt command to support EdDSA algorithm (#118) @AlexanderYastrebov
    • Revert Encoding/Decoding changes for better compatibility (#117) @ajermaky
    • Allow none algorithm in jwt command (#121) @AlexanderYastrebov
    • Unwrap for ValidationError (#125) @kdeberk
    • cmd: list supported algorithms (-alg flag) (#123) @AlexanderYastrebov
    • Added VerifyIssuer method to RegisteredClaims (#130) @tfonfara
    Source code(tar.gz)
    Source code(zip)
  • v4.1.0(Sep 24, 2021)

    • Adds support for go1.17 (#89).
    • Adds RFC7519-compliant RegisteredClaims struct (#15). Use this instead of StandardClaims (deprecated but not removed).
    • Adds generic crypto.Signer for ed25519.PublicKey (#95).
    • Adds regular code scanning (#101).
    • Corrects "exp" logic to conform to https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4 (#86).
    • Adds additional parsing tests (#106).
    • Changed error string (#97).
    • Various Code fixes and cleanup (#53, #83, #102, #103).
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0(Aug 3, 2021)

    • Adds Go module support (#41). You can import this package using the following import path:

    This release, and any future /v4 work is intended to be backwards-compatible with existing v3.x.y tags.

    See the migration guide for more details.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.2(Jul 30, 2021)

    • Starting from this release, we are adopting the policy to support the most 2 recent versions of Go currently available. By the time of this release, this is Go 1.15 and 1.16 (#28).
    • Fixed a potential issue that could occur when the presence of exp, iat or nbf was not required for verification and contained invalid contents, i.e. non-numeric/date. Thanks for @thaJeztah for making us aware of that and @giorgos-f3 for originally reporting it to the formtech fork (#40).
    • Added support for EdDSA / ED25519 (#36).
    • Optimized allocations (#33).
    Source code(tar.gz)
    Source code(zip)
  • v3.2.1(Jun 8, 2021)

    • Import Path Change: See MIGRATION_GUIDE.md for tips on updating your code
      • Changed the import path from github.com/dgrijalva/jwt-go to github.com/golang-jwt/jwt
    • Fixed type confusion issue between string and []string in VerifyAudience (#12). This fixes CVE-2020-26160
    Source code(tar.gz)
    Source code(zip)
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 2.4k May 8, 2022
Safe, simple and fast JSON Web Tokens for Go

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

cristaltech 541 May 16, 2022
A simple and lightweight library for creating, formatting, manipulating, signing, and validating JSON Web Tokens in Go.

GoJWT - JSON Web Tokens in Go GoJWT is a simple and lightweight library for creating, formatting, manipulating, signing and validating Json Web Tokens

Toby 5 Feb 7, 2022
Microservice generates pair of access and refresh JSON web tokens signed by user identifier.

go-jwt-issuer Microservice generates pair access and refresh JSON web tokens signed by user identifier. ?? Deployed on Heroku Run tests: export SECRET

Oleksii Velychko 27 Apr 14, 2022
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 594 May 4, 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 Mar 19, 2022
Herbert Fischer 196 Nov 17, 2021
an stateless OpenID Connect authorization server that mints ID Tokens from Webauthn challenges

Webauthn-oidc Webauthn-oidc is a very minimal OIDC authorization server that only supports webauthn for authentication. This can be used to bootstrap

Arian van Putten 13 May 16, 2022
Minting OIDC tokens from GitHub Actions for use with OpenFaaS

minty Experiment for minting OIDC tokens from GitHub Actions for use with OpenFaaS Why would you want this? Enable third-parties to deploy to your ope

Alex Ellis 9 Oct 31, 2021
Golang jwt tokens without any external dependency

Yet another jwt lib This is a simple lib made for small footprint and easy usage It allows creating, signing, reading and verifying jwt tokens easily

Karpelès Lab Inc. 1 Oct 11, 2021
Utility to generate tokens to interact with GitHub API via GitHub App integration

GitHub App Authentication for integration with GitHub Introduction GitHub Apps are the officially recommended way to integrate with GitHub because of

GitHub Advanced Security 2 Mar 16, 2022
Generate and verify JWT tokens with Trusted Platform Module (TPM)

golang-jwt for Trusted Platform Module (TPM) This is just an extension for go-jwt i wrote over thanksgiving that allows creating and verifying JWT tok

null 2 Mar 2, 2022
Go module with token package to request Azure Resource Manager and Azure Graph tokens.

azAUTH Go module with token package to request Azure Resource Manager and Azure Graph tokens. prerequisites Install azure cli: https://docs.microsoft.

Bart 1 Dec 1, 2021
Generate and verify JWT tokens with PKCS-11

golang-jwt for PKCS11 Another extension for go-jwt that allows creating and verifying JWT tokens where the private key is embedded inside Hardware lik

null 0 Dec 6, 2021
OauthMicroservice-cassandraCluster - Implement microservice of oauth using golang and cassandra to store user tokens

implement microservice of oauth using golang and cassandra to store user tokens

Mehdi 1 Jan 24, 2022
Generate a generic library of 2FA tokens compatible with Google Authenticator

towfa Generate a generic library of 2FA tokens compatible with Google Authenticator go get -u github.com/golandscape/twofa $twofa "you secret" result:

golandscape 13 Mar 23, 2022
Authenticated encrypted API tokens (IETF XChaCha20-Poly1305 AEAD) for Golang

branca.go is branca token specification implementation for Golang 1.15+.

ESSENTIAL KAOS 34 Apr 19, 2022
Authenticated and encrypted API tokens using modern crypto

Branca Token Authenticated and encrypted API tokens using modern crypto. What? Branca is a secure, easy to use token format which makes it hard to sho

Mika Tuupola 183 May 14, 2022
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 284 Apr 23, 2022