In the previous section of the series, I had explained the requirement of sharing session information across multiple web services and the option of a persistent mechanism to do so.

In this section, I will delve into achieving the same objective. But instead of a persistent mechanism (such as a database), I will show you how this can be achieved via a web token.

What is a web token?

Simply put, a web token (in our present context) is nothing but session data that we want to share across multiple services. So let’s say you login using an authentication service you have developed, and provided that you are a valid user, the authentication service fetches data such as your UserID, FullName, UserRole, etc, etc from the database. This could be any information at all! For the sake of compatibility, we will use JSON format to represent the information. So now, the auth server has generated a session id (of course) and a JSON string such as : {"UserID":1, "FullName":"Nirav Kaku", "UserRole":"admin"}.

The server could very well send this string back to share with other services but that wouldn’t be secure, right? Any client can make up a string like that without actually having to login. So what we could do is encode this information using Base64 encoding so the above JSON string would look something like this : eyJVc2VySUQiOjEsICJGdWxsTmFtZSI6Ik5pcmF2IEtha3UiLCAiVXNlclJvbGUiOiJhZG1pbiJ9

However, this too isn’t any proof that it was given by our auth service because Base64 encoding is more or less standard across the globe so anyone would be able to generate that text from the data.

And that’s where HASHING comes in

Hashing is a technique that takes any data and a secret key (think of it like a password for now) and combines them both (using an algorithm) to produce another set of data. So, lets say, I take the above encoded data and *hash* it with my key (password) which, for now, we can assume to be : MySecretKeyForHashing, it would produce a string that looks like this: 4cfc23e0cc4f240e8ff4184cba51d5ef950f00eb53a975848f4c5e3b19c9eb9a

Note

The hash string is different from the encoded data. The special thing about the hash string is that it takes a specific key (password) to produce that exact set of characters! I change my secret key even by a bit, the hash string produced will be completely different for the same encoded data. Here’s what I get if I change the key from MySecretKeyForHashin (removed the g): 21df0b2cb2d32a51209fe2c0d729fa11411865597dd573771b2c3d4be6a7cbdb

Combining the both

You can now take both, the encoded data and the hash string and combine / concatenate them like this using a . in between: eyJVc2VySUQiOjEsICJGdWxsTmFtZSI6Ik5pcmF2IEtha3UiLCAiVXNlclJvbGUiOiJhZG1pbiJ9.4cfc23e0cc4f240e8ff4184cba51d5ef950f00eb53a975848f4c5e3b19c9eb9a

This combined string represents two things:

• The session information is encoded
• And that the session information that has been encoded is definitely encoded only by the real auth service and non other.

Now that you have this combination, your auth server can send this back to the client in a cookie… just like how DMVC by default sends dtsessionid cookie to the client.

The client browser will automatically send this cookie to other services (with in the same Path).

In the next section, I will show how to implement this in Delphi.