As with any new technology, the first implementation is not always the best one. We had to adjust JWT token handling in the front-end and now I’m going to share those experiences.
This post is a follow-up to the previous post which I wrote, called Securing Microservices with JWT tokens. I encourage you to read that first.
At the moment, JWT tokens have been in production use for about half a year and there haven’t been any problems with the tokens itself. The only problem that we had encountered was caused by us misconfiguring the cloud environment.
We have really tried to create stateless services for our microservice architecture, but there was one time when we failed to do so. It was our authentication service which acted as a proxy between microservices and old OAuth2 authentication server. It turned out that we forgot the session which was generated while the user was being authenticated and redirected to the OAuth2 server. After we made our services more resilient by duplicating them, we forgot to use the sticky sessions so that the users would have been always redirected back to the same authentication service instance. This caused occasional failures to the user authentication process as there were no existing session for that user when returned from the OAuth2-server and thus service generated an error. This caused us some gray hairs before we realized the actual problems, the fix was a no-brainer.
Hopefully picture can illustrate the situation more:
At the beginning we used the
Authorization-request header to pass JWT token to the back-end when performing requests from the UI. The token itself was stored in browser’s local storage. It turned out, that this wasn’t the best way when security was in concern. For UI to be able to set JWT token to HTTP headers, it must be able to read JWT token from somewhere.
Using browser’s local storage to store JWT token exposes it to possible XSS (
As the SPA cannot access JWT token anymore, it doesn’t have knowledge of current user’s information (username, roles, etc). Thus we needed to implement an endpoint to the back-end service which could be used to fetch user’s details for UI. The endpoint has been secured so that UI (browser) must send authentication cookie along with the request to be able to access the endpoint.
JWT tokens have still been valid decision to secure our microservices and with authentication cookies, capturing token by a possible attacker is even harder than before.
You can read more about the subject from this related posts:
See what we have to offer - Careers