Creating Authentication Using the Microservices Architecture

Question

I am developing a microservice application and I do not know how to distribute microservices to allow auth.

I read that each microservice should have its own database in order to avoid communication.

The problem is that authentication (via JWT) and Microservices users must have access to the same database and table (s). I believe this problem was resolved before similar applications ran into the same problem.

How can i solve this?

Answer 1

JWS (a signed version of JWT) is a great example, as was considered for similar scnearios:

• you have an authentication application: every login goes through this ( signin.domain.com ), and as soon as you check the credentials of the user you issue the token generated using the private keys strong>
• each service ( service2.domain.com , service2.domain.com ) can implement middleware, which instead of authorization : all your services will receive a public key and will be able to verify the authenticity of the token through this key. They do not need a database, because what they need to check is that the token is valid, and not the one that exists with the user, etc. Etc.

To clarify my last statement: you should probably issue very short tokens. At this point, say that:

• user X logs in
• its token will be valid for ten minutes.
• user X deletes his account but still has a valid token
• He then turns to service.domain.com

In service.domain.com you still consider it registered until, for example, you need to interact with an API that actually gets into the database (i.e. adds a new user address). At this point, the service responsible for writing to the database throws an exception saying that the user does not exist, and you can probably trap him and take the user out of the system. All of this can be tweaked or tweaked, but you'll get a rough idea of ​​how it can work.

Returning to JWT and its use, I do not know if you are familiar with PHP, but this is a pretty simple example .

If you want a fantasy, you can use nginx as middleware and have something like an auth module for authorization for you.

And last, but not least, here we examined only authentication: for authorization, you probably want either in each service or read the user’s roles from the token (if you saved them there as soon as the user logs in) - but this is a little incorrect as if the user had lost the role, then his token listed it anyway) or simply call signin.domain.com/users/me from each service to get an updated list of user roles, and then check if he is allowed to perform certain operations over it th specific service.

Oh, and remember that you should never put sensitive data in JWT / JWS, as it can be decoded. So yes, you can add user roles in JWT, but for example, never save passwords or other plaintext tokens.

Hope this helps!

Answer 2

We solve this by using a set of services to protect services that require authentication. It is very similar to how you approach it if it were a monolith.

As @odino noted:

• Use the Auth service to authenticate the user and create a token (the OAuth stream is used for this)
• Subsequent services will then use the token to check if the user exists by passing it through the Auth service ("composition")

Here is an example with StdLib (what we use inside the house):

 const lib = require('lib'); module.exports = function(params, callback) { lib.user.isAuthenticated(params, (err, user) => { if (err) return callback(err); // We're authenticated – do the rest of the work. }); } 

The caveat to this is that if you use HTTP as a protocol for exchanging data between your services, you significantly add 200-300 ms overhead for your authentication. You can solve this problem by downloading services that require authentication in a single container (StdLib does this out of the iirc box)

Answer 3

We use a slightly different strategy. We missed signing or encrypting JWT, which makes our JWT only Base64-encoded for our token object, and the JWT once created is valid for all of our microservices. We made sure that our microservices are not directly accessible, but only through Api Gateway. The API gateway performs authentication (Http Basic), generates a token, caches the token and checks it for each request, and then passes it as a header when delegating to a microservice. This microservice can access another service simply by transferring the JWT it received from Api Gateway, and we use the JWT as just a mechanism to find out who the registered user is.

After receiving a request, each microservice checks for JWT in the header. If they exist, select the privileges available for the user specified in the token, and use them for authorization. Authorization (privileges) ensures that the right person is trying to access the resource.