JWT - Json Web To
// JSON WEB TOKEN
// A JSON Web Token (JWT) is a JSON object that is defined in RFC 7519 as a safe way to represent a set of information between two parties. The token is composed of a header, a payload, and a signature.
// Formula:
data = base64urlEncode( header ) + “.” + base64urlEncode( payload )
signature = Hash( data, secret );
// Standard fields:
// Issuer (iss) - identifies principal that issued the JWT;
// Subject (sub) - identifies the subject of the JWT;
// Audience (aud) - 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.
// Expiration time (exp) - The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.
// Not before (nbf) - Similarly, the not-before time claim identifies the time on which the JWT will start to be accepted for processing.
// Issued at (iat) - The "iat" (issued at) claim identifies the time at which the JWT was issued.
// JWT ID (jti) - case sensitive unique identifier of the token even among different issuers.
// The following fields can be used in authentication headers:
// Token type (typ) - If present, it is recommended to set this to JWT.[1]
// Content type (cty) - If nested signing or encryption is employed, it is recommended to set this to JWT, otherwise omit this field.[1]
// Message authentication code algorithm (alg) - The issuer can freely set an algorithm to verify the signature on the token. However, some supported algorithms are insecure.[5]
// Definição:
// The purpose of encoding data is to transform the data’s structure. Signing data allows the data receiver to verify the authenticity of the source of the data.
// Main purpose of encryption is to secure the data and to prevent unauthorized access.
// Verifying JWT
// Since the application knows the secret key, when the user makes a JWT-attached API call to the application, the application can perform the same signature algorithm
// The application can then verify that the signature obtained from it’s own hashing operation matches the signature on the JWT itself
// If the signatures match, then that means the JWT is valid which indicates that the API call is coming from an authentic source.