JWT - The JSON Web Token!

Sometimes I use my free time to discover something new (or new for me).

This time it should be the JSON Web Token.

After the first consideration, I didn't understand the use of it at all... 

I (the server) create a token (Header. Payload), make Base64 out of it, and add a signature by hash with a key. 

OK, so far so good. If I send this token to the client, the client can take a look at it with a Base64 decode. 

(Why should I allow the client to do that?).

The client should send me this token with the next request and I (the server) can apply the hash again and check (the client doesn't know my secret key, which I used for the hash), if the hash matches, that is the way I can check, that it is still "my/valid" token. With the payload, I can then identify the user.

Fine - where is the use case?

The server generates the token after the user-login and doesn't need to store this session token. Cool.

How else was it done in the past? 

Generated a GUID, add a few random bytes, then maybe a cipher, and put this into a database. Next time you could just access the database with the token and after the access, you had everything you needed from the user. And the Client does not know anything about the token or what is stored inside - I prefer this, but:

With the JWT, the session database is not needed and the payload of the token can be used to load the user information. Perhaps for your web application, this simple "User is Valid" information is enough! 

The structure of the token is like this:

Base64(Header) "." Base64(PayLoad) "." Base64(Hash("Header.Payload",Key))

Header and Payload are JSON strings. Of course, someone has made countless thoughts about what has to be contained in the JSON. 

So the header could look like this : {"type": "JWT", "alg": "HS256"}

Token type and hash algorithm.

There is also a rule for the payload (RFC 7519). This may all have a justification and looks like this:

{"sub":"Frank Lauter","iat":1610651797,"exp":1610738197,"iss":"FDK-Token"}

Subject, Issuedat (Timestamp), exp (Expiration Time), iss (Issuer) e.g. the library used.

The algorithm works of course also, if you write completely different JSON in there.

One trick you have to keep in mind is that not all characters of the Base64 encoding can be used as URL-Querry-Param. Normally you would think that just a URLEncode is called because it makes the usual %HexValue stories, but this is not so and also the "=" at the end must be deleted. 

Facebook also uses this coding... As Marco wrote 2012!

If you google for "JWT and Delphi" the first link will be a github repo. 

These 24 units - 173KB source - work very well! ;-)

Perhaps you will like the source and if you have to address all the RFC-Rules you might want to use this... 

Or you just write this few lines in your Webbrocker application:

Yes, you have to insert the DateTime JSON Value, and I set it fix to SHA256 bit. 

You need

If you get back the token with the next call you just use:

for this you need the URLDecode:

You can of course improve this little demo and support different Hashes, or use your own content and give a shit about the RFC's - My Server, MyApp, My Rules!

Have fun...