Understanding Jwt (Json Web Token)

Jwt Concept #

• Jwt is a Claim-based Web Token that stores user attributes using the Json format.
• Jwt securely transmits information using a Self-Contained method, where the token itself holds the data.
• Jwt, primarily used for user authentication or information transfer, is processed with the following logic.

When the application runs, the Jwt is stored in a static variable and local storage. The reason for storing it in a static variable is that when making HTTP requests, the Jwt needs to be included in the HTTP header, and continuously loading it from local storage would cause overhead. When the client sends a request including the JWT, the server checks if it's an authorized Jwt. Also, upon logout, the Jwt data stored in local storage is removed. (In a real service, upon logout, the token that was used should be added to a 'blacklist' DB table to prevent access with that token.)

Structure #

• A Jwt consists of three parts: Header, Payload, and Signature. Each part, in Json format, is encoded with Base64Url.
• A separator is used to join each part.
• Additionally, Base64Url is not an encrypted string; it always returns the same string for the same input.

Header #

The token's header consists of two pieces of information: typ and alg. alg does not encrypt the header; it specifies the algorithm for hashing the Signature.

• typ: Specifies the token type, e.g., Jwt.
• alg: Specifies the algorithm method, used for signing (Signature) and token verification, e.g., HS256 (SHA256) or RSA.

{
    "alg": "HS256",
    "typ": JWT
}

PayLoad #

• The token's payload contains claims, which are pieces of information to be used in the token.
• Claims are divided into three types, and multiple pieces of information can be included in Json (Key/Value) format.

Registered Claim #

Registered claims are predefined types of data used to express token information. All are optional but recommended for use. To keep Jwt concise, all keys are 3-character strings. A unique value is used for the subject, typically the user's email.

• iss: Token issuer
• sub: Token subject
• aud: Token audience
• exp: Token expiration time, must be in NumericDate format, e.g., 123456787654
• nbf: Token activation date (not before), the token is not active before this date
• iat: Token issued at time, allows knowing the elapsed time since token issuance
• jti: Jwt token identifier (Jwt Id), used to prevent duplication, for single-use tokens (Access Token), etc.

Public Claim #

• Public claims are user-defined claims used for public information.
• To prevent collisions, a URI format is used, as shown in the example below.

{
    "https://...." : true
}

Private Claim #

{
    "token_type" : access
}

Signature #

• The signature is a unique cryptographic code used to encode or validate the token.
• The signature is generated by Base64Url-encoding the header and payload values created above, then hashing the encoded values using a secret key and the algorithm defined in the header, and finally Base64Url-encoding this result.

Jwt Token Example #

The generated token is used as the value for the key "Authorization" when making HTTP requests. Typically, "Bearer" is prefixed to the value.

"Authorization" : "Bearer {생성된 토큰 값}",

Jwt Disadvantages and Considerations #

• Self-contained: The token itself contains information, which can be a double-edged sword.
• Payload Encoding: The payload itself is not encrypted; it is Base64Url-encoded. If the payload is intercepted and decoded, the data can be viewed, so it should either be encrypted with JWE or important data should not be placed in the payload.
• Stateless: Since JWT does not store state, once created, it cannot be controlled. This means it's impossible to arbitrarily delete a token, so an expiration time must always be included.
• Store Token: Tokens must be managed on the client side, so they need to be stored.