These days, Token authentication is the best methodology to authenticate users to our web applications. The reason for the popularity of Token authentication because of its speed, when compared to the traditional session-based authentication in some scenarios and gives us some additional flexibility. In this article, we can learn about how we have implemented token authentication in Spurtcommerce: what it is, how it works, why we should we use it, and how it has been used.

What is Token Authentication

Token authentication is a method to authenticate users before they enter into an application using a temporary token (typically a JSON Web Token) instead of actual credentials.

• The way this works in the context of web authentication is like this. • A user wants to log into a website. • A user provides their email address and password to the website (their credentials). • The website generates a token for that user. • The user’s browser stores the token. • As the User makes continuous requests to the website, their token will be sent along with their request. • The website will validate the token and use it to authenticate that user.

The main advantage of this method is that tokens contain embedded information about the user, so the website can receive the token and find out who the user is and what permissions they have and this is done without the need to talk to a central database. This means one may not need to maintain a session store.

Here’s a diagram that will show how the flow has been implemented in our Spurtcommerce Solution.

What are JSON Web Tokens and How we have adopted this in Spurtcommerce

A  token is a component that is used for authenticating a user to a server. Tokens contain embedded user data that is used to identify and authenticate the user.

JSON Web Tokens (JWTs) are an open standard that defines a secure way to transmit information between parties using a JSON object. JWTs are always cryptographically signed (sometimes encrypted) and can be signed using a secret key (symmetrical) or a public/private key pair (asymmetrical).

JWTs are the most popular type of tokens and are often what people mean when they refer to  “token authentication”  in general.

Here’s what a typical JWT look like in it’s compacted, URL-safe form:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImp0aSI6ImJlOTc2MWM2LTRmYTQtNDg2YS04NWQ4LTU0NGZiZGI2YmEzOCIsImlhdCI6MTYwNzA5MjEwOSwiZXhwIjoxNjA3MDk1NzA5fQ.K0PUqI19pz2a50kvPBOitXBPaMXdGlkbhPexcKS04Bc

While this may look complicated and unreadable at the first glimpse, it isn’t actually all that difficult to implement. JWTs consist of three parts, separated by dots (.): xxxxxx.yyyyyy.zzzzzz. These sections represent the JWT header, payload, and signature, respectively.

Let us now understand each section separately.

The JSON Web Token Header

The JWT header is a Base64URL-encoded JSON object. It contains information describing the type of the token and the signing algorithm that has been used, such as HMAC, SHA256, or RSA.

For example:

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

The JSON Web Token Payload

The JWT payload contains something called  claims, which are statements about the entity (typically the user) and additional data.

There are three different types of claims:  registered, public, and private claims. Claims are the most “interesting” part of a JSON Web Token, as they contain data about the user, who needs to get authenticated.

A set of predefined claims (RFC 7519) are optional, but recommended. Some examples are  iss (issuer),  exp (expiration time), and  sub (subject).

Custom claims (claims we defined when creating a token) are used to share information between parties that have access to the token. They are neither  registered or public  and can be whatever we want them to be.

In our example token above, the payload looks like the following:

{
"sub": "1209876543",
"name": "spurtcommerce",
"admin": true,
"iat": 1607092109,
"exp": 1607095709
}

As it can be seen, there are various claims defined which the client and/or server may use to “learn” more about the user.

The JSON Web Token Signature

The JWT signature field is created by taking the encoded header, the encoded payload, a secret key, and using the algorithm specified in the header to cryptographically sign these values.

For example, if we are using the standard symmetrical HMAC SHA256 algorithm, the signature will be created by computing:

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret
)