Introduction
JWT (JSON Web Token) is an open standard that allows transmitting of data between parties as JSON. It is digitally signed so the information is trusted and verified. It can be signed using public / private key (ECDSA or RAS) or made secret with HMAC algorithm. It is very popular in web development.
Structure of JWT
It consists of three parts: Header, Payload, and Signature; all are separated by the dots(.). So JWT looks like - "hhhhhhhhhh.ppppppppp.ssssssss".
Header
It consists of two parts: the hashing algorithm being used such as HMAC SHA256 or RAS, and the type of token, that is, JWT.
Example
- {
- "alg": "HS256",
- "typ": "JWT"
- }
This JSON is Base64Url encoded and becomes the first part of the JWT
Payload
The second part of the JWT is a payload that contains the claims. Claims are the statements about the entity, such as a user. And also, the payload contains the additional metadata. There are three types of Claims: Registered, Public, and Private.
Registered claims are set of predefined claims that are recommended but not mandatory. Here, the claim names are three characters long, so JWT is as compact as possible. Following are the Registered claims
- iss (Issuer)
- sub (Subject)
- aud (Audience)
- exp (Expiration Time)
- nbf (Not Before)
- iat (Issued At)
- jti (JWT ID)
Public claims can be defined at will by those using JWTs. To avoid the collisions, claims should be defined in IANA JSON Web Token Registry or be defined as a public name that contains a collision resistant namespace.
Private claims are the custom claims that are created to share the information between producer and consumer. They are neither registered or public claims.
Example
- {
- "sub": "Test JWT",
- "name": "Trivedi Jignesh",
- "admin": true
- }
This JSON is Base64Url encoded and become second part of the JWT.
Signature
To create the Signature part, we have to use encoded header and payload, a secret that used by the algorithm specified in the header and sign that. The signature is used to verify that the message wasn't changed in transition.
Example
If we are using the HMAC SHA256 algorithm, the signature will be created in the following way,
- HMACSHA256(
- base64UrlEncode(header) + "." +
- base64UrlEncode(payload),
- secret)
The output is three base64 strings that are separated by dots which can be easily passed in HTML and HTTP request and more compact than the SAML (Security Assertion Markup Language Tokens - XML based standards). The following shows JWT.
- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJUZXN0SldUIiwibmFtZSI6IlRyaXZlZGkgSmlnbmVzaCIsImFkbWluIjp0cnVlfQ==.X5ZYZxrVGlrcegeJmNjKj_dA02pDvfkQCjwAy2y3V9k
We can also play with JWT and put these concepts into practice. We can use
jwt.io debugger to decode, verify and generate JWT.
How JWT works
As in authentication, after the user successfully logs in using their credentials, a JSON Web Token will be returned. The tokens are a way to authenticate the request, so we must care of the token to prevent security issues. The token is always to be sent with each request typically in the Authorization header using the Bearer schema.
- Authorization: Bearer <<token>>
This is a stateless authentication mechanism in which user state is never saved in server memory. The server route will check a valid JWT in Authorization header and if it is present, the user will be allowed to access protected resources. The JWT contains the all the necessary information.
The safest and simplest way to implement JWT-based authentication is to use one of the existing open source libraries. In JWT.io, we can find several libraries for .NET, Python, Java, Ruby, Swift etc.
There are many types of tokens available, such as SWT (Simple Web Token), SAML (Security Assertion Markup Language) token and JWT (JSON Web Tokens). In this section, we talk about the benefit of JWT over SWT and SAML token.
The JSON is less verbose than the XML. When JSON is encoded, its size is smaller than encoded XML data, so JWTis more compact than the SAML. This is the reason JWT is a good choice to be passed in HTML and HTTP environments.
SWT is asymmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML can use a public/private key in the form of X.509 certificate for signing. Signing the XML with Digital Signature without introducing obscure security holes is very difficult. It is the very simplicity of signing JSON.
JSON is supported in most programming languages due to its quality of mapping directly to the objects whereas XML doesn't have a natural document-to-object mapping. So, it is easier to work with JWT than SAML token.