This is already a kind of an abstract “opinion” question so I sort of want to let it drop. But, my personal opinion is that, yes, you might want to look into an API gateway. But it does depend the complexity of your requirements for auth/auth. Because, yes, one of the advantages of an API gateway is to centralize auth/auth and abstract it from the services. And if later you think you might need to take advantage of other API gateway features (reporting, logging, abstraction, versioning/migrating, rate limiting, billing, etc.) then you have it in place.
Ingasi is right (of course) that if your needs are simple enough than you could write one. Ignasi showed his example, I think there is another example in Kevin Webber’s “Full Stack Reactive” example: https://www.lightbend.com/blog/full-stack-reactive-in-practice-webinar . But it already seems like you would benefit from off the shelf auth/auth behavior and auth/auth behavior is something that I always try avoid writing from scratch.
I don’t claim to be an expert on the API gateway space. But the two I know off the top of my head that are primarily open source are Kong and Tyk. (I think both Mulesoft and Smartbear have some parts that are open source, but I don’t think their API gateway parts are.) But if you are saying “open source” just because you don’t have a lot of money to spend you might want to look at the cloud vendors too. Because Kong and Tyk both have commercial components to them as well.
One more thing I’d add though, is that you mention microservices “talk to each other”. Avoid having microservices call each other via sync methods like REST/gRPC. That leads to lots of complexity and performance problems. Follow the Lagom pattern of having microservices communicate to each other asynchronously via events (e.g. Kafka).