Modelon Solutions

When i hear the word Token  –  i think of a random string of text that if i send it to some endpoint, it will be traded for something else (i.e. the ability to confirm account).

For example, if i click on this link in an en email :

http://www.reallygoodsite.com/confirmAccount?OKJASDIUERKSDNHKJASHDKAJDH

i would expect to confirm the account represented by the token OKJASDIUERKSDNHKJASHDKAJDH. Some advice here, i would also expect this token to expire if i don’t click on it in a reasonable amount of time; I would also expect to be able to use the token exactly once.

Now this token is opaque to the user, as in he cannot understand what it means, it’s kind of like an ID, it has no real meaning except to represent something in somme system.

But what if we wanted the token to represent something, allow it to convey information from one system to another. And that’s what JWT’s (JSON Web Tokens) are. Get started with a web helper here.

A JWT is usually three base64 segments separated by a dot, like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2p3dC1pZHAuZXhhbXBsZS5jb20iLCJzdWIiOiJtYWlsdG86ZXJpa0BleGFtcGxlLmNvbSIsIm5iZiI6MTQ4MDc3NzQzNiwiZXhwIjoxNDgwNzgxMDM2LCJpYXQiOjE0ODA3Nzc0MzYsImp0aSI6ImlkMTIzNDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9yZWdpc3RlciJ9.rykcVqxUx-qmV-bbJ79zRAA84tj3eIBJbv-OMx4mUE0

Each segment can be decoded independently. The first carries a JSON containing the signing algorithm information, the second carries a JSON with the claims (actual data) and the last contains a signature so that the authenticity of the token can be verified. The third part of JWT can be absent if the JWT is not signed. Like this :

JSON algorithm information

{“alg”:”HS256″,”typ”:”JWT”}

JSON claims

{"iss":"https://jwt-idp.example.com","sub":"mailto:erik@example.com","nbf":1480777436,"exp":1480781036,"iat":1480777436,"jti":"id123456","typ":"https://example.com/register"}

Signature

) VTƩm{4@ -w 8xA4

The signature is based on an symmetric algorithm, both the creator and the receiver of the token must share a secret. If the algorithm is assymetric, the creator needs access to a private key but anybody with the public key can verify the authenticity of the JWT.

The fun thing about JWT is that there are some standard claims to help with interoperability, all optionial and completely extendable. For example:

iss - Issuer
sub - Subject
nbf - A valid not before date
exp - An expiration date
iat - Issued date
jti - the JWT's ID
typ - the type of claims carried
aud - to whom this JWT is intended for

Modern authentication mechanisms use these JWT “en masse”. If the receiver of a JWT verifies :

1. the signature to ensure that the JWT has not been tampered with
2. the nbf and exp to ensure that JWT is valid at this point in time
3. the iss to ensure that the token was created by then identity provider itself
4. the aud to ensure that this token is targeted at the current service performing the authentication
5. the sub to know who this JWT authenticates.

You have the means to have a great and secure token based authentication system.

Have fun !