Applications have traditionally persisted identity through session cookies, relying on session IDs stored on the server-side. This method brings a few significant problems and pitfalls: it is not scalable, because you need a common point where you can store sessions and, every time a user is authenticated; the server will need to create a new record in a data source. Therefore, this approach may become a significant bottleneck for your web service. 

Nowadays, token authentication can be helpful to authenticate and authorize users, especially in a distributed system context. The main strength of token-based authentication lies in the fact that the consumer asks for a token to an identity service. Next, the client can store the token locally and use it for authentication and authorization purposes.

Therefore, token authentication is stateless and designed to be scalable. Let's have a look at the token-authentication process and how it works, to better understand the benefits of this kind of approach:

This schema describes a typical workflow when implementing token-based authentication. The schema describes three entities:

• The client is the application that is trying to access our resources.
• The identity provider is the service that, given a username and a password, provides an encrypted authentication token.
• The resource provider is another service called by the client. Furthermore, the resource provider will accept the encrypted authentication token, and it will provide the information requested by the client if it is authorized.

Since token-based authentication has a stateless approach, the application doesn't store the authentication tokens. Therefore, it is essential to note that the client must pass the authentication token in every request.

Token-based authentication can be implemented in different ways. JSON Web Token (JWT) is a standard, defined in the RFC 7519 (https://tools.ietf.org/html/rfc7519) open directive, which describes a way to represent claims between two parties. JWT is defined as a JSON object, which contains the payload, and a signature, which encrypts the data in the token. In other words, it provides a way to encrypt secure data formatted as JSON through the use of a secret key. The JWT token standard has become quite popular in recent years because web services can use it for two purposes:

• Authorization: The web service returns a JWT token to transfer information about claims and personal details to signed-in users. Moreover, single sign-on features and token authentication features use this technique to transfer data to the client.
• Information exchange: You can use the JWT token standard to prevent data exploitation and to certify the authenticity of the data you have received by signing it with the provided key.

The JWT token anatomy is very similar to the structure of a web request. It is composed of three parts: header, payload, and signature. The header part contains information about the token type and the signing algorithm used by the token:

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

In that case, we can deduce that the token uses the HMAC SHA256 algorithm, and it is a JWT token type. The payload part is the core part of our token, and it contains the information to be sent to the user. By default, there is a set of predefined information to populate, for example, the exp (expiration time) field. The following JSON is an example of a payload:

{
  "email": "[email protected]",
  "nbf": 1546196276,
  "exp": 1546801076,
  "iat": 1546196276
}

The email field is a claim for the token. nbf stands for not valid before, and iat stands for issued at. The three fields represent the time calculated since the UNIX epoch.

Finally, the signature part of the token signs the encoded header and the encoded payload with the secret key and the algorithm specified in the header.

The resulting encoded token is similar to the following:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InNhbXVlbGUucmVzY2FAZ21haWwuY29tIiwibmJmIjoxNTQ2MTk2Mjc2LCJleHAiOjE1NDY4MDEwNzYsImlhdCI6MTU0NjE5NjI3Nn0.yQGT1TJYL4U_IqBpoQ6MjUchET06BRE-YJ0sf-MRA

It is crucial to note that each point separator (.) in the encoded token represents an encrypted token, as described earlier.