Until now we had out application generate a unique 64 character key (ApiKey) and a session cookie upon login. The session cookie would also include the ApiKey. Upon each request, the system would verify the ApiKey.
We just finished re-building our login and request handling to work with JWT (Json Web Token) instead. In short this works similar, the token should be sent with each request, and the system would verify if this token is valid.
The difference is that the JWT includes a signature which is encrypted with a private key, and any change to the payload would be caught quickly. This leads to having a verified payload to work with. The payload can include any kind of information, this with the fact that this information is verified, leads to less database look ups which ultimately translates to a faster application. Instead of querying for this information with each request, only the requested information will be queried (if the user has the required permission).
It is very important to mention that it is ill-advised to include any information in the payload that can lead to the user’s information, for example
name… This token can be intercepted by hackers and as such we need to keep the information as anonymous as possible. Using UUIDs makes it also a bit more difficult to know whose this information really belong to (from outside the system).
The shown payload above might very well be intercepted by a hacker, but they won’t be able to do anything with it. All information is hidden, and if they did add a permission into the payload and then sent a request, the signature will be invalid. Thus, the request will not be handled.