0

I'm building a web application using Spring Boot for the backend and Angular for the frontend and planning on using JWTs signed with HMAC-SHA256 for authentication/authorization.

I've been thinking about what would be the best place to store the secret key and i've come up with the idea that i'd simply generate a random key when starting the server (and would not persist it anywhere) and use that to generate/verify the tokens.

I think this approach would be quite simple to implement and more secure than persisting the key.

The only downside i see is the issued tokens would become invalid on server restarts.

I haven't really seen this anywhere, so i'm not sure if it's a stupid idea or not.

Any insight would be appreciated.

1

If your app is such that you can use short-lived tokens (30 minutes or less), server restarts probably won't be much of an issue for most of your clients.

Where it becomes more of a problem is if you need to horizontally scale your server. Think of the future, where you've had success and need to scale up, i.e. using a system like Spinnaker with Kubernetes to dynamically spin up additional servers. If you don't persist your tokens so they can be shared across all your servers, your clients will somehow need to be bound to their originating server (perhaps by using "sticky sessions" in your load balancer.) You could also solve this by persisting the issued tokens (not the secret keys, just the tokens themselves) but you then have to make sure only your genuine servers can add tokens to your cache. That takes validation, too.

No matter what, there will be extra complexities if you scale up. There's always more to consider.

1

I get why you would want to rotate your secret key during a server restart. But, I believe the same can be achieved by managing the expiry time of your issued tokens. Moreover, it would improve the user experience, since users won't have to authenticate every time you restart the server.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.