What Is JSON Web Token (JWT)?

A web token is a secure format for exchanging and transmitting sensitive data between two nodes or parties in a self-contained block. Amongst its numerous use cases, they are particularly known for strengthening authentication processes within and beyond the scope of an application.

According to Gartner, JWT is the preferred web token for authentication usages. JSON Web Token (JWT) is a web token based on the open standard of RFC 7519. Its basis is a JSON object which securely transmits information in a self-contained manner between stakeholder parties. It contains all the relevant data about the node or entity, which minimizes querying a database repeatedly.

In this blog post, we’ll discuss in detail JWT and how it’s used for authentication in CrafterCMS.

What are JWTs?

A JSON Web Token (JWT) allows multiple parties to exchange data within themselves resolutely. For quite some time, common methods used for user authentication were web cookies. Even today, for certain purposes this method works well. But on some occasions, more flexibility is needed. And that is where JSON web token comes into play. It is a newer and open standard, and it is dominantly used by many of the significant websites and apps.

According to RFC 7519, a standardized access token has all the meaningful information about entities, meaning none of the database queries are needed. Sessions are not required to be saved on the server.

JWT Structure

It consists of three parts, and all of them are separated by a point and encoded using Base64. (HEADER.PAYLOAD.SIGNATURE). Let's look at each of them in detail.

Header

The header typically contains two parts, and it gives important information related to the token. It has the type of token and encryption/signing algorithm being used. A JWT header can look like this.

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

Payload

It holds the information about valid and authenticated users. There are certain standards maintained for how and what data should be transmitted. This information is located as key/value pairs. For example, a JWT payload could look like this.

{ "sub": "123", "name": "Alice", "exp": 30 }

Signature

This is the most important part. The signature of the JSON web token was created using Base64 encoding of the header and payload and the mentioned signing algorithm. The JSON Web Signature (JWS) decides its structure which is a standardized recommendation of RFC 7515. A JWT signature can look somewhat like this.

signature = HS256(base64Header + '.' + base64Payload, 'secret')

// dyt0CoTl4WoVjAHI9Q_CwSKhl6d_9rhM3NrXuJttkao

JWT Claims

There are two types of JWT claims.

Reserved

These JWT claims are defined to ensure interoperability with external or third-party applications. Some of the recommended reserved claims for interoperability within the third party applications include:

  • iss (issuer) JWT issuer.
  • sub (subject) JWT subject (the user).
  • aud (audience) JWT recipient.
  • exp (expiration date) JWT expiration time.
  • nbf (not before time) JWT not be accepted before time.
  • iat (issued at time) JWT issued time.
  • jti (JWT ID ) Unique identifier.
Custom

These are claims that you can define yourself. To avoid collision with reserved claims or any other custom claims these claims need to be named carefully, otherwise multiple claims with the same name but that have different information may contradict each other.

{
“sub”: “Chriskane”,
”iat”: “16432383”
}

Benefits

JWT accesses public/private key pairings for signing, so the signature also certifies that the signed tokens using a public/private key are the only ones signed holding the keys. JWT is trusted and verified because the information contained in it is digitally signed.

Comparison

The security capabilities of JSON Web Tokens (JWT) can be compared with Simple Web Tokens(SWT) and Security Assertion Markup Language Tokens(SAML).

When JSON is encoded, its size becomes smaller, making JWT more compact than SAML, and an ideal choice.

SWT uses the HMAC algorithm for symmetrically signing compared to JWT, and SAML uses public/private keys pairings. For signing, they use an S.509 certificate. JSON parsers map directly to objects and are mostly used in programming languages while XML does not, making it a lot easier to work with JWT than SAML.

Uses

Here are some of the scenarios where web tokens are most useful:

  • Authorization: Tokens permit users to access resources, routes, and services whenever the user logs in. 
  • Information Exchange: The main idea of JSON web tokens is to transmit information to parties securely. By enabling public/private key pairs, you can be aware of the sender of who they are and what they say. 
  • Authentication: One of the most popular uses for the JWT token is its API authentication mechanism. You set up the API,  and receive the secret token from the service. The secret token is used to create another token on the client-side for signing. The unique identifier is enabled, and the server will have complete knowledge of the specific client.

JWT can prevent unknown authorization, allows smooth distribution of information within the servers, and increases service efficiency by organizing a single entry point for many services with the same login data.

However, it could also put your system at an entire risk of mishandling the technology, compromising the users’ data.

To use JWT safe and secure, it is recommended to:

  1. Use secure protocols while transferring tokens
  2. Not allow transferring sensitive data in tokens
  3. Make sure to validate the data received from the user
  4. Choose authentic libraries for JWT operations

Crafter Studio’s Authentication Using JWT

With the usage of APIs, organizations interact with content authoring and management systems. Crafter Studio is the authoring platform within CrafterCMS.

The basics of interacting with Crafter Studio’s APIs are as follows.

  1. Authentication API.
  2. APIs to get the list of sites with which the user is authorized to work.
  3. Write content for a project.

The most widely used authentication methods are JWT and HTTP basic. HTTP basic is disabled by default as it is not as secure as JWT. For either authentication method, you need to know the right credentials of a user. So first, generate the token for the admin user. However, if the token management tool is not present in the global menu, you can get the required permission manage_access_token to create the token from the system administrator. Below are a few steps to access the token using Crafter Studio.

To access the token, you need to do the following:

  1. Log in to Crafter Studio.
  2. Access the Token Management Tool.
  3. Create New Access Token.
  4. Copy the value of the access token.

CrafterCMS and JWT Combine

CrafterCMS uses JWT to authenticate in front of our APIs. It makes integration with Crafter simpler, because with JWT as the standard, developers can more easily build those integrations. DevContentOps is facilitated through integrations with various DevOps tools. JWT standardizes APIs and allows Crafter to be ready for integration with tools like JIRA, Trello and more.

DevContentOps allows developers, content managers, IT operations, and different workflows to perform their jobs seamlessly without any resistance. Content can move backward to lower environment levels that allow deployment teams to have flexibility in their approach and developers and content authors go work together in parallel.

As a process, DevContentOps can be implemented manually or via automation. Automation is the preferred approach and this can be orchestrated via APIs. JWT is then used to standardize API authentication and authorization to DevContentOps support APIs.

CrafterCMS provides a platform for developers, content authors, and operations to work together in collaboration. As it is an open-source platform, developers can use any frontend framework on top of crafter's headless content server. In addition, CrafterCMS includes a powerful backend and native Git support that allows you to manage code, content, and configurations, enabling seamless collaboration among developers, content authors, and IT ops.