Skip to content
loading...

re: How I Fixed JWT Security Flaws in 3 Steps VIEW POST

TOP OF THREAD FULL DISCUSSION
re: That's a good question! What I would do is: The public endpoint extracts the JWT from the cookie (sent with the HTTP request) Process the JWT to...
 

So you're suggesting to have a single public service which proxies requests to other backend services? This is actually how we have just implemented this at my work. 🙂

However, my question was how you would approach it if you had multiple services your frontend could communicate with directly. One of the advantages of JWT is that any service with access to the signing secret can verify the token and trust the claims within. So, in theory, if an auth service issues the token to the frontend, then another service can receive and decode the token without involving the auth service again. But how can we secure the token on the frontend in this case?

In that case, I can see two options:

  1. Each public endpoint has the secret and can decode the JWT by itself
  2. A single internal service is dedicated to decoding the JWT, which would serve multiple public endpoints whenever they need
Implementation Pros Cons
Distributed secret Reduced complexity and latency Secret is more exposed, repeated functionality across different services reduces maintainability¹
Dedicated JWT decoder Reduces attack surface, more maintainable May increase services coupling, increased latency

¹ Some architectures have resources to mitigate that. The JWT decoding could be implemented as a Layer, if you're using AWS Lambda, for example.

Side comment: I would be very interested in reading more about the implementation you and your team are using! Do you have any plans to write about it? I see pros and cons about proxying requests from a single endpoint.

code of conduct - report abuse