this post was submitted on 29 Jan 2026
25 points (96.3% liked)

Programming

25400 readers
392 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

I hope this post fits in this community :)

I'm trying to wrap my head around how authentication works with micro services.

Say we have a system, with a frontend, that communicates with an API gateway, which in turn communicates with all the micro services.

As I understand it, we authenticate the client in the API gateway, and if we trust the client, the request are forwarded to the micro services.

However, what is stopping a malicious actor from bypassing the API gateway and communicating directly to the micro services ?

Do we solve this problem using a firewall, so only trusted traffic reaches the micro services ?

Or do we still have API keys between the API gateway and the micro services ?

Or is there a third way ? :)

All the articles I've read seem to assume, that we can trust all traffic entering the micro services

you are viewing a single comment's thread
view the rest of the comments
[โ€“] MagicShel@lemmy.zip 2 points 1 week ago* (last edited 1 week ago)

Without considering any other security measures:

  • The client authenticates with the identity provider and receives a signed JWT
  • When the request hits the API Gateway, the gateway checks the signature with the auth service to make sure it hasn't been tampered with (whether this is internal or external โ€” imagine if one of your servers was compromised, you still don't want it to be able to forge a JWT with any rights beyond what the service is supposed to have)
  • If the JWT is valid, the gateway forwards the request to the service and the service can trust it without validation (I think. We haven't gotten to this part yet.)
  • Requests with invalid JWTs are dropped
  • The API Gateway can also handle refresh tokens invisibly.
  • A compromised API gateway obviously could then forge JWTs so if you want you can have each service check signatures on their own, but the advantage of the gateway is that you have a single point of vulnerability to harden rather than trust each service developer to correctly validate the token on their own.

So you can write the validation part once. I happen to be tech lead on a project to write this mechanism, so it's pretty fresh in my head.