Use JWT (JWS) for authentication

Earlier days we used sessions to validate users and we used different architectures to manage sessions. With the evolving of requirements and web traffic plain old monolithic applications were not able to fulfill the performance needed. Then developers tend to divide load among multiple nodes and the sessions needed to share with them.

As a solution, we can use token-based authentication where authentication server will generate a new token according to the login request and send it back to the client. Which each request where the authentication is necessary client can send the acquired token along with the request and server can validate the token. Token-based authentication is prominent everywhere on the web nowadays. With most every web company using an API, tokens are the best way to handle authentication for multiple users.

There are some very important factors when choosing token-based authentication for your application. The main reasons for tokens are:

  • Stateless and scalable servers
  • Mobile application ready
  • Pass authentication to other applications
  • Extra security

JSON Web Tokens (JWT)

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.

Parts of a JWT


The header typically consists of two parts: the type of the token, which is JWT, and the hashing algorithm being used, such as HMAC SHA256 or RSA.

“alg”: “HS256”,
“typ”: “JWT”


The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional metadata. There are three types of claims: registered, public, and private claims.

  • Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud(audience), and others.
  • Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
  • Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or publicclaims.
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true


To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:

base64UrlEncode(header) + "." +

The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.

Putting all together

The output is three Base64-URL strings separated by dots that can be easily passed in HTML and HTTP environments, while being more compact when compared to XML-based standards such as SAML.

The following shows a JWT that has the previous header and payload encoded, and it is signed with a secret.


Other token types

  • SWT (Simple Web Token)
  • SAML (Security Assertion Markup Language Tokens)

Token based authentication workflow

Token generation (Authentication server)

When the client sends an authentication request to authentication server then the authentication server will generate a JWT token and send it to the client (When signing authentication token we can use symmetric or asymmetric encryption methods)

Token Read (Client)

Since the payload and header is only encoded values. The client can easily decode and read those values

Do not add sensitive information is JWT payload because it is visible to everyone

Token Validation (Application server)

When the client needs to access secured content JWT token need to send along with the request and the application server need to validate it.

Validation workflow change with the encryption method (Symmetric or Asymmetric)

Symmetric (Shared key)

Asymmetric (Private/public key)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.