Security considerations when using JSON Web Tokens (JWT)

Security implementations for RESTful API calls are paramount. Whether it is a web-service API that you are exposing to third-party, or creating an AngularJS/KnockoutJS web application, your service end-points increase the risk of your API being exploited and compromised. It is therefor important to consider (not only the security risks highlighted by OWASP) but also ensure that your end-points are vulnerable despite your security implementations.

The follow table depicts possible security implementations for RESTful calls:

Type Context Example
Username/password URL/Body https://api.acme.org/v1/endpoint?username=abc&password=123
HMAC URL/Body https://api.acme.org/v1/endpoint/token
API Key URL/Body https://api.acme.org/v1/endpoint/apikey
JWT HTTP Header Authorization: Bearer ABC123

For public facing websites, I favour JWT. Factors that should be considered:

  • HTTPS (Secure connections)There are various options in obtaining SSL certificates – from paid for single and multi-domain, to free certificates via Cloudflare and Letsencypt. Cloudflare is a good option as this mitigates DDoS attacks, boost performance, and hide the live origin server IP.
  • Encrypt payload
  • Rotating keys (https://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html)
    • Expire within n hours (where n=24hrs)
    • Everything < n  should be cached and validated
    • Requests >= n is denied access to resource
  • Security tokens (like JWT) should always originate at the server to ensure integrity. Tokens should not be manipulated in any way on the client-side. Not only would the integrity/checksum fail, but you’ll expose private keys to the public which would compromise the security aspect severely.
  • Rotating keys (https://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html)The theory behind rotating keys are that the payload contains a unique (cached) identifier that will ever only be used once. If you consider the anatomy of a token middleware on the the RESTful API, tokens are inspected with each hit that is made on the private end-points. (Not all end-points needs tokens that required validation – for example,
    • Expire within n hours (where n=24hrs)
    • Everything < n  should be cached and validated
    • Requests >= n is denied access to resource

 

Leave a Reply

Your email address will not be published. Required fields are marked *