JSON Web Tokens (JWT) — the basics

Authorisation

At first, I shall mention, there are more, than just one way of doing this; You can use either some database or in-memory data structure store. Such as Redis. Then all you do is, you save session in your memory, you store session ID inside of your token’s payload, and you simply compare your session with token, client is passing to you. This way has definitely some pros, for instance — you’re able to create a blacklist, for users tokens you don’t want to be active anymore. Or you can treat your database as a whitelist — only sessions stored in the memory would be authorised then. But this definitely requires you to have additional database service, which makes your query response a bit longer. Maybe not long enough to make any sort of difference, but it’s worth mentioning.

Matching Identity

So, you’re now authorized to use the app. But how does it happen, so with simple token, the application is able to find your data? Well, it’s quite tricky, as there are at least two ways of doing this. Maybe even three, that are used widely.

Security

You may wonder, “How do I know the token is valid? And how do I know whether the token isn’t modified on the go?”. Well, those are valid concerns, but the answer for those is really simple: secret key. JWTokens are signed with a secret on your backend. That way, every time someone tries to authenticate with a token that’s signed by different string, it won’t much, therefore user won’t get authenticated.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store