Be careful with JWT and third-party auth services

Last Update: 17.04.2020. By Jens in Newsletter

JWTs are great if you use some precautions. Like, don’t put sensitive stuff in it. But it surprisingly happens often. It is a recurring theme in my consultations that devs forget that signed and encoded does not mean encrypted. And so user details end up in the token that should not be there like personal data, billing URLs and hosts.

JSON Web Tokens are only signed and encoded. That means anyone obtaining the token can decode it with easy and see what you stored in it. The only secure thing is that they can not tamper with it as the token is signed.

Never forget that and be spares with the stuff you put in a token.

Sometimes this can happen by accident too. For example, when using an auth lib or service you aren’t familiar. Like it happened within a side project of mine using the Netlify Identity service. It’s almost of out the box auth service with a small Javascript frontend and a service running in your deployment instance. It uses JWTs and works with their functions aka lambdas. Pretty smoothly.

Their API offers two fields to add app and user-specific data to the user object. Nicely explained in the Javascript library how you can use them. However, what they missed to mention is that whatever you put in there is also put into the token. The whole user object is put in there.

That is convenient as you have everything in the token that your backend might need. No extra request for retrieving user details. It’s tempting to put more in there. But it can also create holes when you are not aware of that.

I wasn’t until some time later it strikes me that I should check what they actually put into that token. And voila, everything was there. Doh!

So, be careful and double-check what you put into tokens and what your auth service actually does :-).