Browser API is used, token will not be transmitted to the cloud.
- Basic
- Registered Claim
- Custom Claim
- Secret
- All in One
The online JWT (JSON Web Token) generation tool supports the use of multiple algorithms to generate JWT tokens, and supports setting standard payloads and custom data. It also supports generating encrypted JWT tokens (Encrypt JWT).
- This tool supports generating JWT (JSON Web Token) through JWS (JSON Web Signature) and JWE (JSON Web Encryption). This tool also supports parsing JWT, and the corresponding key needs to be entered during parsing.
-
Basic : Set the basic parameters for JWT encoding and decoding.
- Category : Select whether the encoding and decoding object is JWT (JWS) or Encrypt JWT (JWE).
- Algorithm(alg) : Select the signature algorithm used for JWT encoding and decoding. JWS support HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, EdDSA . JWE support A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW, A256GCMKW, dir, RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384, RSA-OAEP-512, PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW, ECDH-ES, ECDH-ES+A128KW, ECDH-ES+A192KW, ECDH-ES+A256KW .
- Encrypt(enc) : Select JWE encryption algorithm, support A128GCM, A192GCM, A256GCM, A128CBC-HS256, A192CBC-HS384, A256CBC-HS512 .
- Type(typ) : Set or display the JWT typ header value.
-
Registered Claim : Set or display the JWT Registered Claim.
- "iss" (Issuer) Claim : The "iss" (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The "iss" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
- "exp" (Expiration Time) Claim : The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
- "sub" (Subject) Claim : The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
- "aud" (Audience) Claim : The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case- sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.
- "nbf" (Not Before) Claim : The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the "nbf" claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the "nbf" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
- "iat" (Issued At) Claim : The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
- "jti" (JWT ID) Claim : The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case- sensitive string. Use of this claim is OPTIONAL.
- Custom Claim：Custom payload for JWT.
- Secret : The key used for JWT encoding and decoding format depending on the algorithm's required key format. This tool supports String, Hex, Base64, and PKCS8_PEM, SPKI_PEM, X.509, JSON Web Key (JWK) key format.
- JSON Web Token : Click Encode, and the generated JWT results will be displayed here. When clicking on Decode, JWT needs to be entered here.
- Encode : Generate a JWT using the filled in parameters.
- Decode : Parse a JWT and display the data contained within it. Decoding only requires the use of Algorithm(alg), Secret, and JSON Web Token parameters.
What is JSON Web Token?
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
When should you use JSON Web Tokens?
Here are some scenarios where JSON Web Tokens are useful:
- Authorization : This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
- Information Exchange : JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.
What is the JSON Web Token structure?
In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are: Header, Payload, Signature. Therefore, a JWT typically looks like the following:xxx.yyy.zzz.
- Header : The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
- Payload : The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
- Signature : To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
