JWT Fingerprints with a REST API
Significantly improve JWT token security for your customers and you.
Including a System JWT Issuing Fingerprint within the JWT token could deliver you significant security improvements without any inconvenience to your users….
It’s a win, win… or if you don’t agree, let me know why!
JWT Fingerprint:
If you’re creating a JWT token then you’re issuing it to someone and that means it was requested. The fingerprint of the requesting system is a much overlooked component in securing JWT tokens.
Requesting systems may be identified by a number of parameters:
IP address: and from that, country, ISP, organisation or ASN number, see https://ipwhois.app/json/8.8.8.8
User agent: and from that, many unique properties, see:
Language: and from that, many unique properties
Depending on just how sensitive you require your JWT fingerprint to be depends on how many parameters you combine to create your fingerprint.
I combine the following headers to create a base line fingerprint, sec-ch-ua, user-agent, accept-language and upgrade-insecure-requests.
That just leaves IP address which can be combined directly, or you could combine, ASN, ORG or country dependent on your own use cases.
Leaving IP address out entirely still gives a highly unique fingerprint.
Here’s a sample fingerprint from my own web browser:
192.168.1.250 : “Google Chrome”;v=”89", “Chromium”;v=”89", “;Not A Brand”;v=”99" : Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 : en-GB,en-US;q=0.9,en;q=0.8 : 1
ip.no : sec-ch-ua : user-agent : accept-language : upgrade-insecure-req
So I now have a system fingerprint which was generated at the same time as the JWT Token was requested. I can add or remove elements from it dependent on my particular use case. Typically you may wish to replace the IP address with either the country, ISP, organisation, ASN number or remove it and use known header information only.
Create a 32 byte MD-5 hex checksum (any checksum) of your fingerprint.
MD-5 hex of concatenated fingerprint system data:
8344b6e8b488a7ac8e502d5481905656
Add the issuing system fingerprint to your JSON Payload:
Valid JWT tokens with an unmatched issuing system fingerprint require re-authentication and issue of a new token.
Conclusion:
If an a bad actor gains control over a valid token they also need to gain control over the issuing system for it to be valid thereby adding a significant layer of protection to your underlying API design whilst allowing no database lookups and processed from known header information only.
Existing tokens are valid against the system that issued them.