Microservice authentication architecture with passport.

Question

I am writing a toy for practical microservices and authentication on nodes (expressjs).

I have a client-client, authentication service, and other services (they just say "hi" so far).

• The client will be hosted on the CDN.
• The authentication service is listening on port 5000 (for example)
• Other services are listening on port 6000-6100.
• I have redis db for storing session information (oauth token provided by twitter).
• Mongodb, where the information about the application is stored (not relevant to this issue).

The idea is that an unauthenticated client is sent to the authorization service by clicking the Twitter (SSO) button. The auth service then receives the generated oath oath token and sets that token to the redis repository. Then the token is available to other services so that they know whether the request is checked or not, if it already exists in the redis store (if the user deletes his account, he will also be deleted from the redis store), I send the twitter token back and forth from the client to server after authentication.

I find this approach quite simple (others use the nginx proxy server for authentication, but I see no reason for this, except when the services are located in different domains, but I do not understand them very well), so I worry For example, I missed something about security.

Questions:

• Is this approach right?
• Can I share a Twitter token (I think so)?
• Is there a security issue that I don’t notice here?

Answer 1

Using this approach, you will have to check the token in all your services, if you are ok with this, then you are probably fine.

The twitter access token may have an expiration time that will require the use of an update token to obtain a new access token from the auth service:

• When the access token expires, you must return 401 to the client from service X that you are trying to talk to.
• The client will have to call the Auth service providing the update token, receiving a new access token
  • Finally, the client again hits Service X with this new access token, validates it, and receives the expected response from Service X.

In my recent appointment, I wrote a microservice that proxied all tokens using this approach, my proxy handled everything from auth to roles and sends 401 for expired tokens and cancels update tokens, etc. I think this gave me a greater separation of concerns.

Important Note: In the upgrade token scenario, only an invalid / expired accesstoken will be downloaded above my proxy, while in your scenario any service can be reached with invalid tokens ...

Another approach would be to allow Services A and Service-B to call an authentication service to check for tokens, but this will lead to a significant increase in traffic between services, since every HTTP request with a token needs to be checked. In this case, also an invalid token request will reach your Service X and, therefore, will put some load on it ...