What is the most common stateless way for authentication in microservices?

Question

I'm trying to get into Microservices by creating a project, so far I've stumbled upon authentication mechanisms, in a monolithic architecture, the client (web app) would send a request with the user credentials to receive a JWT and send it in every upcoming request. However, when it comes to Microservices I found out that there were two different ways to achieve the same, stateless authentication mechanism, either by delegating the authentication and authorization responsibilities to the gateway service, or by using OAuth2 (or OpenID Connect??). Most online resources recommend OAuth2, however isn't it used for service-to-service authorization? Should I use the authorization code flow with password grant?

The API is only going to be accessed by a single client (web app), so no other service is going to ask the user for their data consent or something.

Answer 1

NOTE This answer is not relevant to the question due to confusion about the use case. I am leaving it for now in case it's helpful to anyone else.

I don't know if it's the most common but this is a perfect use case for using client-certificates. This is also referred to as mutual authentication (mTLS)

Part of what makes this appealing in this kind of situation is that you likely are already managing a certificate on the client (the web-server.) If you aren't then you should fix that first. The only difference between a server-certificate and a client-certificate is that the latter is signed to allow it to be used for client authentication. This means that one certificate can be used for both its server-authentication and its client-authentication. You just need it signed for both capabilities.

mTLS is built into the TLS standard and generally requires no additional libraries. If a request can't produce an acceptable cert, they are stopped before they get an opportunity to poke at any part of your web API. The biggest challenge tends to be figuring out how to make your host accept them and pass the identity details (e.g. subject) to the auth module of your framework. One fairly simple approach is to let a reverse-proxy do this and pass these details along on a header. Just make sure you clear anything that a client (attacker) might try to pass in on that header or headers.