jwt/search/search_index.json

{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Getting Started","text":"<p>Welcome to <code>jwt-go</code>, a go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens. </p>"},{"location":"#supported-go-versions","title":"Supported Go versions","text":"<p>Our support of Go versions is aligned with Go's version release policy. So we will support a major version of Go until there are two newer major releases. We no longer support building jwt-go with unsupported Go versions, as these contain security vulnerabilities which will not be fixed.</p>"},{"location":"#what-the-heck-is-a-jwt","title":"What the heck is a JWT?","text":"<p>JWT.io has a great introduction to JSON Web Tokens.</p> <p>In short, it's a signed JSON object that does something useful (for example, authentication).  It's commonly used for <code>Bearer</code> tokens in OAuth 2.0  A token is made of three parts, separated by <code>.</code>'s.  The first two parts are JSON objects, that have been base64url encoded.  The last part is the signature, encoded the same way.</p> <p>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.</p> <p>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.</p>"},{"location":"#whats-in-the-box","title":"What's in the box?","text":"<p>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, ECDSA and EdDSA, though hooks are present for adding your own.</p>"},{"location":"#installation-guidelines","title":"Installation Guidelines","text":"<p>To install the jwt package, you first need to have Go installed, then you can use the command below to add <code>jwt-go</code> as a dependency in your Go program.</p> <pre><code>go get -u github.com/golang-jwt/jwt/v5\n</code></pre> <p>Then import it in your code:</p> <pre><code>import \"github.com/golang-jwt/jwt/v5\"\n</code></pre>"},{"location":"#jwt-and-oauth-20","title":"JWT and OAuth 2.0","text":"<p>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.</p> <p>Without going too far down the rabbit hole, here's a description of the interaction of these technologies:</p> <ul> <li>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.</li> <li>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. This is also specified in the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens, detailed in RFC 9068.</li> <li>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 TLS.</li> </ul>"},{"location":"usage/create/","title":"Creating a New JWT","text":"<p>One of the primary goals of this library is to create a new JWT (or in short token).</p>"},{"location":"usage/create/#with-default-options","title":"With Default Options","text":"<p>The easiest way to create a token is to use the <code>jwt.New</code> function. It then needs one of the available signing methods, to finally sign and convert the token into a string format (using the <code>SignedString</code> method). In the first example, we are using a symmetric signing method, i.e., HS256. For a symmetric method, both the signing and the verifying key are the same and thus, both must be equally protected (and should definitely NOT be stored in your code).</p> <pre><code>var (\nkey []byte\nt   *jwt.Token\ns   string\n)\nkey = /* Load key from somewhere, for example an environment variable */\nt = jwt.New(jwt.SigningMethodHS256) // (1)!\ns = t.SignedString(key) // (2)!\n</code></pre> <ol> <li>This initializes a new    <code>jwt.Token</code> struct    based on the supplied signing method. In this case a symmetric method is    chosen.</li> <li>This step computes a cryptographic signature based on the supplied key. </li> </ol> <p>Signing using an asymmetric signing method (for example ECDSA) works quite similar. For an asymmetric method, the private key (which must be kept secret) is used to sign and the corresponding public key (which can be freely transmitted) is used to verify the token.</p> <pre><code>var (\nkey *ecdsa.PrivateKey\nt   *jwt.Token\ns   string\n)\nkey = /* Load key from somewhere, for example a file */\nt = jwt.New(jwt.SigningMethodES256) // (1)!\ns = t.SignedString(key) // (2)!\n</code></pre> <ol> <li>This initializes a new <code>jwt.Token</code> struct based on the supplied signing method. In this case a asymmetric method is chosen.</li> <li>This step computes a cryptographic signature based on the supplied private    key.</li> </ol> <p>Note, that the chosen signing method and the type of key must match. Please refer to Signing Methods for a complete overview.</p>"},{"location":"usage/create/#with-additional-claims","title":"With Additional Claims","text":"<p>While the step above using <code>jwt.New</code> creates a valid token, it contains an empty set of claims. Claims are certain pieces of information that are encoded into the token. Since they are encoded and signed by the issuer of the token, one can assume that this information is valid (in the scope of the issuer). Claims can be used to provide the basis for user authentication or authorization, e.g., by encoding a user name or ID or roles into the token. This is also commonly in combination with OAuth 2.0. Furthermore, claims can also contain certain metadata about the token itself, e.g., the time until which the token is regarded as valid and not expired.</p> <p>RFC 7519 provides a list of so called registered claim names 1, which each JWT parser needs to understand. Using the <code>jwt.NewWithClaims</code>, a token with different claims can be created.</p> <pre><code>var (\nkey *ecdsa.PrivateKey\nt   *jwt.Token\ns   string\n)\nkey = /* Load key from somewhere, for example a file */\nt = jwt.NewWithClaims(jwt.SigningMethodES256, // (1)!\njwt.MapClaims{ // (2)!\n\"iss\": \"my-auth-server\", // (3)!\n\"sub\": \"john\", // (4)!\n\"foo\": 2, // (5)!\n})\ns = t.SignedString(key) // (6)!\n</code></pre> <ol> <li>This initializes a new <code>jwt.Token</code> struct based on the supplied signing method. In this case a asymmetric method is chosen, which is the first parameter.</li> <li>The second parameter contains the desired claims in form of the <code>jwt.Claims</code> interface. In this case <code>jwt.MapClaims</code> are used, which is a wrapper type around a Go map containing <code>string</code> keys.</li> <li>The <code>\"sub\"</code>3 claim is a registered claim name that contains the subject this token identifies, e.g. a user name. More technical, this claim identifies the principal that is the subject of the token.</li> <li>The <code>\"iss\"</code>2 claim is a registered claim name that contains the issuer of the token. More technical, this claim identifies the principal that issued the token.</li> <li>The <code>\"foo\"</code> claim is a custom claim containing a numeric value. Any string value can be chosen as a claim name, as long as it does not interfere with a registered claim name.</li> <li>This step computes a cryptographic signature based on the supplied private    key.</li> </ol>"},{"location":"usage/create/#with-options","title":"With Options","text":"<p>While we already prepared a <code>jwt.TokenOption</code> type, which can be supplied as a varargs to <code>jwt.New</code> and <code>jwt.NewWithClaims</code>, these are strictly for future compatibility and are currently not used.</p> <ol> <li> <p>Section 4.1 of RFC 7519 \u21a9</p> </li> <li> <p>Section 4.1.1 of RFC 7519 \u21a9</p> </li> <li> <p>Section 4.1.2 of RFC 7519 \u21a9</p> </li> </ol>"},{"location":"usage/parse/","title":"Parsing and Validating a JWT","text":""},{"location":"usage/parse/#keyfunc","title":"Keyfunc","text":""},{"location":"usage/parse/#with-options","title":"With Options","text":"Option Name Arguments Description <code>WithValidMethods</code> methods as <code>[]string</code> Supplies a list of signing methods that the parser will check against the algorithm on the token. Only the supplied methods will be considered valid. It is heavily encouraged to use this option in order to prevent \"none\" algorithm attacks.1 <code>WithJSONNumber</code> - Configures the underlying JSON parser to use the <code>UseNumber</code> function, which decodes numeric JSON values into the <code>json.Number</code> type instead of <code>float64</code>. This type can then be used to convert the value into either a floating type or integer type. <code>WithIssuer</code> issuer as <code>string</code> Configures the validator to require the specified issuer in the <code>\"iss\"</code>2 claim. Validation will fail if a different issuer is specified in the token or the <code>\"iss\"</code> claim is missing. <code>WithSubject</code> subject as <code>string</code> Configures the validator to require the specified subject in the <code>\"sub\"</code>3 claim. Validation will fail if a different subject is specified in the token or the <code>\"sub\"</code> claim is missing. <code>WithAudience</code> audience  as <code>string</code> Configures the validator to require the specified audience in the <code>\"aud\"</code>4 claim. Validation will fail if the audience is not listed in the token or the <code>\"aud\"</code> claim is missing. The contents of the audience string is application specific, but often contains the URI of the service that consumes the token. <code>WithLeeway</code> leeway as <code>time.Duration</code> According to the RFC, a certain time window (leeway) is allowed when verifying time based claims, such as expiration time. This is due to the fact that a there is not perfect clock synchronization on the a distributed system such as the internet. While we do not enforce any restriction on the amount of leeway, it should generally not exceed more than a few minutes.5 <code>WithIssuedAt</code> - Enables a sanity check of the <code>\"iat\"</code>6 claim. More specifically, when turning this option on, the validator will check if the issued-at time is not in the future. Danger Zone <ol> <li> <p>https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries \u21a9</p> </li> <li> <p>Section 4.1.1 of RFC 7519 \u21a9</p> </li> <li> <p>Section 4.1.2 of RFC 7519 \u21a9</p> </li> <li> <p>Section 4.1.3 of RFC 7519 \u21a9</p> </li> <li> <p>Section 4.1.4 of RFC 7519 \u21a9</p> </li> <li> <p>Section 4.1.6 of RFC 7519 \u21a9</p> </li> </ol>"},{"location":"usage/signing_methods/","title":"Signing Methods","text":""},{"location":"usage/signing_methods/#signing-vs-encryption","title":"Signing vs Encryption","text":"<p>A token is simply a JSON object that is signed by its author. this tells you exactly two things about the data:</p> <ul> <li>The author of the token was in the possession of the signing secret</li> <li>The data has not been modified since it was signed</li> </ul> <p>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, JSON Web Encryption (JWT)1, that provides this functionality. The companion project https://github.com/golang-jwt/jwe aims at a (very) experimental implementation of the JWE standard.</p>"},{"location":"usage/signing_methods/#choosing-a-signing-method","title":"Choosing a Signing Method","text":"<p>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.</p> <p>Symmetric signing methods, such as HMAC, use only a single secret. This is probably the simplest signing method to use since any <code>[]byte</code> 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.</p> <p>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.</p>"},{"location":"usage/signing_methods/#signing-methods-and-key-types","title":"Signing Methods and Key Types","text":"<p>Each signing method expects a different object type for its signing keys. The following table lists all supported signing methods in the core library.</p> Name <code>\"alg\"</code> Parameter Values Signing Key  Type Verification Key Type HMAC signing method2 <code>HS256</code>,<code>HS384</code>,<code>HS512</code> <code>[]byte</code> <code>[]byte</code> RSA signing method3 <code>RS256</code>,<code>RS384</code>,<code>RS512</code> <code>*rsa.PrivateKey</code> <code>*rsa.PublicKey</code> ECDSA signing method4 <code>ES256</code>,<code>ES384</code>,<code>ES512</code> <code>*ecdsa.PrivateKey</code> <code>*ecdsa.PublicKey</code> RSA-PSS signing method5 <code>PS256</code>,<code>PS384</code>,<code>PS512</code> <code>*rsa.PrivateKey</code> <code>*rsa.PublicKey</code> EdDSA signing method6 <code>Ed25519</code> <code>ed25519.PrivateKey</code> <code>ed25519.PublicKey</code>"},{"location":"usage/signing_methods/#frequently-asked-questions","title":"Frequently Asked Questions","text":"<p>Why is the HMAC signing method not accepting <code>string</code> as a key type?</p> <p>We often get asked why the HMAC signing method only supports <code>[]byte</code> and not <code>string</code>. This is intentionally and there are different reasons for doing so. First, we aim to use the key type that the underlying cryptographic operation in the Go library uses (this also applies to the other signing methods). In case of HMAC, this is <code>hmac.New</code> and it uses <code>[]byte</code> as the type to represent a key.</p> <p>Second, using <code>string</code> as a key type to represent a symmetric key can lead to unwanted situations. It gives the impression that this is something 'human readable' (like a password), but it is not. A symmetric key should contain as much entropy as possible and therefore include characters from the whole character set (even 'unreadable' ones) and ideally be generated by a cryptographic random source, such as <code>rand.Read</code>. Signing tokens with a cryptographically weak key will compromise the security of the tokens and in effect everything that depends on it, e.g., user authentication.</p> <p>If you have trouble handling a <code>[]byte</code> key in our setup, e.g., because you are reading it from your environment variables on your cluster or similar, you can always use base64 encoding to have the key as a \"string\" type outside of your program and then use <code>base64.Encoding.DecodeString</code> to decode the base64 string into the <code>[]byte</code> slice that the signing method needs.</p> <ol> <li> <p>RFC 7516 \u21a9</p> </li> <li> <p>Section 3.2 of RFC 7518 \u21a9</p> </li> <li> <p>Section 3.2 of RFC 7518 \u21a9</p> </li> <li> <p>Section 3.2 of RFC 7518 \u21a9</p> </li> <li> <p>Section 3.2 of RFC 7518 \u21a9</p> </li> <li> <p>Section 3.1 of RFC 8037 \u21a9</p> </li> </ol>"}]}