What about a microservice architecture, where one service may handle authentication and issuing tokens, but those tokens can then be used to authenticate to other services? If you use a cookie to store the token in this case, you can't rely on the browser forwarding it to other services due to privacy settings. ๐ค
The public endpoint extracts the JWT from the cookie (sent with the HTTP request)
Process the JWT to extract the User object
When invoking other microservices internally, pass the User object with the requests
If I'm implementing an event-driven architecture, I would maybe include only the User ID (to avoid bloating the messages too much), and each microservice can retrieve the entire User object from a database storage
That's actually the same thing if the JWT was coming as a header or in the request body payload. The public endpoint would need to extract and pass around to internal services anyway...
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?
Each public endpoint has the secret and can decode the JWT by itself
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What about a microservice architecture, where one service may handle authentication and issuing tokens, but those tokens can then be used to authenticate to other services? If you use a cookie to store the token in this case, you can't rely on the browser forwarding it to other services due to privacy settings. ๐ค
That's a good question!
What I would do is:
That's actually the same thing if the JWT was coming as a header or in the request body payload. The public endpoint would need to extract and pass around to internal services anyway...
Does that make sense? ๐
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:
ยน Some architectures have resources to mitigate that. The JWT decoding could be implemented as a Layer, if you're using AWS Lambda, for example.