Best way to perform authentication between microservices?

Hey, I currently thinking about a good way to authenticate a user between my microservices. My current solution is that I generate a JWT Token and when somebody makes a API access he has to add the token into the header. Now the API makes a request to another service, and asks if the token from the header is value. The authentication service now gives back that the token is valid or invalid. I don´t think that this is a good solution, so I want to ask if you now a better solution.

So, if I get it correctly, you want a way to authenticate a user when passing information between microservices? Or do you want a way to authenticate the microservice itself?

Terminologies

You don't want to be confused between authentication, and authorization. Let me quickly define it:

authentication - Checking if the person is someone who he really claims to be; you do this by providing a username + password.
authorization - Checking if the person has the right to access some resource. This is usually done by giving a token generated by the authentication process, or something like that.

The AuthBearer does both. First, it creates a token when the user asks it to; and, when the microservices give it a token, it checks for authorization.

Auth a User Between a Microservice

For this, I'd recommend you create a AuthBearer microservice. Now, let this service handle everything (Authentication + Authorization); create REST routes like:

/services/auth/token (POST)

{
    status: 200,
    data: {
        "token": "...."
    }
}

When a user requires authentication, send his/her data to this service, and it'll return a token; JWT, if you prefer. Now, if he uses some other service, ask him to pass that token as a Header, and then from within that service, ask the Bearer if it's valid.

A quick example; say you have the following microservices:

product - add a product;
checkout - checkout a list of products;
auth - the auth service

The first microservice would be /services/product, the second one will be /services/checkoutand the third one will be /services/auth. Now, to authenticate, the user sends the his/her details to /services/auth, and this microservices returns a JWT. Perfect.

He, then, creates a product by POSTing it to the /services/product route, with his header Auth <TOKEN> Bearer. Upon getting this header, the Product microservices asks the Auth microservice if the token provided is valid; if it is, it gives the permission, otherwise a 401.

If you need help with anything else, be sure to comment! I hope this helps! :)

Gunther Verhemeldonck, granted. But instead of introducing that, I thought of giving a easy introduction for an auth service. After experimenting whatever fits him, he can choose the way he wants to go. This serves in two ways: i) he can do some research and experimentation, so instead of a stone-cold path, he has options; and ii) starts him with a gentle introduction.

And what if the product micro service would call checkout micro service(which is secured), Does the product service should send any identity information in a rest call to checkout service? If no, how does the secured checkout service would allow the product service to call it and fetch the response from checkout.

In case we are using J.WT there is obviously no need to call Auth service to check token is valid or not instead respective microservice will verify the token itself using public key provided or secret key provided thats the advantage of JWT we dont need to call Auth service again and again for validity or fetching user info from DB again and again

To complement @labsvisua's answer, I think a really important point is - to have only a single auth endpoint that handles the jwt signature generation/check and return 200,401 - but to avoid calling the auth from every single other services. That second point is critical from my point of view. All the auth validation should be handled at the API gateway level, and once forwarded to a (micro)service , that service can trust the request. All your auth tests/updates belong to your api gateway, therefore if you have anything to update/fix/improve/add regarding auth, it's done in single one place (and therefore it's much more easier to test)

We're not using Kong , but we usually refer to their doc to explain this: getkong.org All the user-facing common 'boilerplate stuff' (auth, versions, ...) is centralized in an api gateway so that all your other services can focus on their real purpose, and you don't have the risk of having multiple (and possibly outdated) versions of your auth lib all over the place.

I thought of giving a simple base for him to build his system on. That way, he'll have the problems firsthand, and while debugging, he'll learn as well! ;)

Depending on your use case, this might not be an acceptable solution. If you trust anything that comes from inside your network, a hacker only needs to compromise one machine to have a free lunch on all of your internal APIs.

To avoid this, every micro service needs to verify if the request has valid authentication. This could be done by poking the Auth service on every request (this can cause a lot of trafic) or using a technique like JWT tokens.

If you go with JWT, you'll need to share encryption keys with all of your micro services. This might or might not be a good idea, depending on your use case.

Yeah sure, but ideally, the "one machine" should be limited/restricted to the facing one(s) (ie bastion/nat), and all the others should be in a private subnet, so that the only point of failure to watch for is that gatekeeper. Depending how much overhead you can afford and how critical the data is, then the tradeoff have to be made, and there's no one-size-fit-all solution ;-)

Thread

Best way to perform authentication between microservices?

Responses(2)

Terminologies

Auth a User Between a Microservice

Recent threads

Search Hashnode

Best way to perform authentication between microservices?

Responses(2)

Terminologies

Auth a User Between a Microservice

Recent threads