JWT(JSON Web Token)

Overview

JWT(JSON Web Token) 내용정리.

Basic

A JSON Web Token is a compact and self-contained way for securely transmitting information between parties as a JSON object, and they are commonly used by developers in their APIs. JWTs are popular for the below reasons.

A JWT is stateless. That is, it does not need to be stored in the database(persistence layer), unlike opaque tokens.

The signature of a JWT is never decoded once formed, thereby ensuring that the token is safe and secure

A JWT can be set to be invalid after a certain period of time. This helps minimize or totally eliminate any damage that can be done by a hacker, in the event that the token is hijacked.

JWT format

A JWT is comprised of 3 parts.

• Header: the type of token and the signing algorithm used.

The type of token can be "JWT" while the Signing Algorithm can either HMAC or SHA256.

• Payload: the second part of the token which contains the claims. These claims include application-specific data(e.g, user id, username), token expiration time(Exp), issuer(is), subject(sub), and so on.

• Signature: the encoded header, encoded payload, and a secret you provide are used to create the signature.

This is a JWT, and consists of 3 parts(separated by .).

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6InVzZXIxIiwiZXhwIjoxNTQ3OTc0MDgyfQ.2Ye5_w1z3zpD4dSGdRp3s98ZipCNQqmsHRB9vioOx54

can be tested here: https://jwt.io/

How the JWT signature works

So if the header and signature of a JWT can be read and written to by anyone, what actually makes a JWT secure? The answer lies in how the last par(the signature) is generated.

Making the header and payload are pretty straightforward: The header is more or less fixed, and the payload JSON object is formed by setting the user ID and the expiry time in Unix milliseconds.

The application issuing the token will also have a key, which is a secret value and known only to the application itself. The base 64 representations of the header and payload are then combined with the secret key and then passed through a hashing algorithm.

Verifying a JWT

In order to verify an incoming JWT, a signature is once again generated using the header and payload from the incoming JWT, and the secret key. If the signature matches the one on the JWT, then the JWT is considered valid.

Token types

Since a JWT can be set to expire(be invalidated) after a particular period of time, two tokens will be considered in this application.

• Access Token: An access token is used for requests that require authentication. It is normally added in the header of the request. It is recommended that an access token have a short lifespan, say 15 minutes. Giving an access token a short time span can prevent any serious damage if a user's token is tampered with, in the event that the token is hijacked. The hacker only has 15 minutes or less to carry out his operations before the token is invalidated.

• Refresh Token: A refresh token has a longer lifespan, usually 7 days. This token is used to generate new access and refresh tokens. In the event that the access token expires, new sets of access and refresh tokens are created when the refresh token route is hit.