What is the best way to implement authentication in a microservice architecture?

Question

JSON Web Token

Good day to all. I have a question, maybe someone can help me. I am designing a microservice architecture using the Gateway API for each type of client, and I need advice in terms of user authentication. Please tell me the best way to authenticate. I explain: I have a main REST API that plays the role of a proxy server, well, a router, there are a couple of microservices (sending email, working with media, a user service, and a separate authorization service). So here's the best way to do it optimally, and without overheads. In my understanding, there are two options.
Option 1. Some request comes from the client to the API Gateway, for example /users/updatePhoto, and the request headers contain JWT. The API Gateway sends a request to the authentication service with an embedded token. If the authentication service gives a positive response, then the request is carried out further to the service required by the client.
Option 2. A request comes from the client to the API Gateway, for example, to /users/updatePhoto. The API Gateway immediately redirects the request to the required microservice, and in the context of each microservice, requests will be made to the authorization microservice via the message broker (RabbitMQ).
Or I see it all wrong, and there is some other option.
I would be very glad to any advice from a knowledgeable person, since he himself is a layman in building a microservice architecture, and this is my first experience).

Answer 1

Late, perhaps, but better late than never.
The two most important questions are:
1. What is the scope of the project? On a 10-point scale from 0 (online store) to 10 (eBay). Wangyu, which is no more than 3-4 most likely.
2. Are all microservices in a private network or scattered across the world wide web? Again, most likely the first.
If my assumptions are correct, then:
1. Fuck OAuth and other hemorrhoids. You are too young for this, you need to do everything as simply and concretely as possible. Flexibility and speed are always bought with man-hours, there are no miracles. Complete the basic requirements of susurity (brypt, mortal tokens, etc.) and no more. Write something yourself, simple, understandable, and easily maintained by programmers of the level you can hire. You will fit into 50 lines of code.
2. Put nginx at the input, which will ask the authentication microservice with a subrequest for each incoming request: "here is a request, such headers, such a url, who is it? let him in?". And write on something like Go a reader from the user base, which will give you an answer to such a question in 3 ms (and nginx will stick "Vasya" to the request and send it further or kick it off). And if there is no big load, then it can be slower, there is no need to be afraid of a delay of 15 ms for each request, this is a completely justified price for simplicity and the absence of a zoo of languages ​​and technologies.
Here I posted a very minimalistic example: github.com/bitia-ru/examples-microservices-authent...

Answer 2

Any oAuth 2.0 are thought up just for this purpose.
https://habr.com/ru/company/mailru/blog/115163/
Another thing is that they are used for other purposes and in smaller projects.
But the main point is that authentication goes in a separate way, independent of your microservice.
I would not warm my head, but would take a ready-made API gateway
https://konghq.com/faqs/
This is by no means.
Seriously bogs down performance.
Why do you need GWT?
To avoid such as you described.
If you want to request all the same every time, then not "from the authentication service through a message broker" but from some common memcache/Redis/Tarantool.

Answer 3

Why ask for the validity of the token from the most important person for each request?
Passed authorization, received a token, the authorization service itself communicates through its channels with all services in the cluster and sends them a message that such a token is valid, in fact, only after tokens are sent to everyone - authorization will be completed (and you can send a response with this token to the user ).
Similarly, there is a forced withdrawal of the token (log out).
Token - abstractly, it is a unique code plus authorization parameters - validity period and access rights

Answer 4

And where should the services store this valid token?
And the client has a token stored, as I understand it, in the memory of the client application?
I'm talking about access-token ..