JWT

Know the component and how to use it.

Micaella Mazoni avatar
Written by Micaella Mazoni
Updated over a week ago

IMPORTANT: This documentation has been discontinued. Read the updated JWT (NEW) documentation on our new documentation portal.

JWT creates JWS and JWE as well as JWS verification and JWE decodification.

Take a look at the configuration parameters of the component:

  • Operation: "Generate JWS" creates JWS tokens. "Generate JWE" creates JWE tokens. "Verify JWS" verifies a JWS token signature and "Decode JWE" decrypts the JWS token and returns this token payload.

  • Public Key: PUBLIC-KEY account type used to sign JWS tokens with the following algorithms: RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, and ES512. Also used to encrypt JWE tokens with the following algorithms: RSA1_5, RSA-OAEP, and RSA-OAEP-256. If the algorithm uses RSA, the public key must be derived from a private key of at least 2048 bits, otherwise, an ECDSA key must be used.

  • Private Key: PRIVATE-KEY account type used to verify JWS tokens with the following algorithms: RS256, RS384, RS512, PS256, , PS384, PS512, ES256, ES384, and ES512. Also used to decrypt JWE tokens with the following algorithms: RSA1_5, RSA-OAEP, and RSA-OAEP-256. If the algorithm uses RSA, the public key must be derived from a private key of at least 2048 bits, otherwise, an ECDSA key must be used.

  • Secret Key: SECRET-KEY account type used to sign JWS tokens with the following algorithms: HS256, HS384 e HS512. Also used to encrypt and decrypt JWE tokens with the following algorithms: A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW and A256GCMKW.

  • Key as Base64: if enabled, the Secret Key account must be in base64 format; otherwise, it must contain the value of the key to be used.

  • Key Charset: if the Key as Base64 property is enabled, the key charset must be informed.

  • JWS Algorithm: algorithms used to sign and verify JWS tokens: HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, and ES512.

  • JWE Algorithm: algorithms used to encrypt and decrypt JWE tokens: A128KW, A192KW, A256KW, A128GCMKW, A192GCMKW, A256GCMKW, RSA1_5, RSA-OAEP and RSA-OAEP-256.

  • Encrypted Payload Algorithm: algorithms used to encrypt and decrypt JWE tokens payload: A128KW, A192KW, A256KW and A256GCM.

  • Issuer (iss): a claim "iss" (issuer) identifies the main one that issued JWT. This claim processing is generally specific from the application. This claim is optional.

  • Expiration Time (exp): a claim "exp" (expiration time) identifies the expiration time in which or after which JWT CAN’T be accepted for processing. The processing of the “exp” request demands the date / time to be previous to the expiration date / time listed in the “exp” request. This claim is optional.

  • Issued at (iat): a claim "iat" (Issued at) identifies the time when JWT was issued. The statement can be used to determine the JWT age. Its value MUST be a number. This claim is optional.

  • Subject (sub): a claim "sub" (subject) identifies the JWT subject. The statements in a JWT are usually about the subject. The subject value MUST locally exclusive in the issuer context or globally exclusive. The processing of this claim is generally specific from the application. This claim is optional.

  • Token Id (jti): the claim "jti" (JWT ID) provides an exclusive identificator for JWT. The identificator value MUST be given to minimize the chances of the same value to be accidentally assigned to an object of different data. If the application uses multiple issuers, the collisions MUST be also avoided between the values produced by different issuers. The claim “jti” can be used to avoid JWT to be repeated. This claim is optional.

  • Audience (aud): single value. The claim "aud" (public) identifies the JWT recipients. Each principal that intends to process JWT MUST identify itself with a value inside the claim reivindication. If the one responsible for the claim processing doesn’t identify itself with a value in the claim “aud” when this claim is present, JWT MUST be declined. This claim is optional.

  • Not Before (nbf): the claim "nbf" (not before) identifies the time before which JWT CAN’T be accepted for processing. The “nbj” complaint processing demands the current date / time to be previous or equal to the date / time listed in the “nbf” complaint. The implementers CAN predict a small safety margin - generally no more than a few minutes - to compensate the distortion in the timer. Its value MUST be a number. This claim is optional.

  • Custom Claims Specification: if the option is enabled, the form to add claims will be hidden and RAW mode submission will be available for you to inform the claims as JSON objects. But if the option is disabled, the custom claim specification form will be used.

  • Custom Claims: to specify custom claims, just inform the key (name of the claim) and the claim value.

  • JWE: field to inform the JWE token.

  • JWS: field to inform the JWS token.

  • Payload Charset: charset of the payload used in the creation of JWE tokens. Standard value: UTF-8

  • Payload: payload to be used in the JWE token creation.

  • Fail On Error: if the option is enabled, the execution of the pipeline with error is suspended; otherwise, the pipeline execution proceeds, but the result will display a false value for the "success" property.

Some of the parameters above support Double Braces. To better understand how this language works, read our article by clicking here.

Messages flow

Input

No specific input message is expected. All it takes is to fill the required fields of each operation.

Output

For the “Generate JWS” operations:
{
"success": true,
"jws": "<JWS TOKEN>",
}

For the “Generate JWE" operations:

{
"success": true,
"jwe": "<JWE TOKEN>",
}

For the “Verify JWS" operations:

{
"success": true,
"verified": true,
"claims": [
"subject": ".....",
"issuedAt": 11111111
]
}

For the “Decode JWE" operations:

{
"success": true,
"payload": "<PAYLOAD DESCRIPTOGRAFADO>"
}
Did this answer your question?