CODEWITHSUNDEEP
node.jsauthenticationauthorizationmicroservicesroles
OhLongJohnJohnson
OhLongJohnJohnson

Reputation: 181

How to authenticate and authorize in a microservice architecture

Short: How to authenticate and authorize role-based users in a microservice architecture?

Long: Say that you have the architecture given below. I am struggeling to see what would be the best practice solution for securing such an architecture. When i search i get alot of different answers.

"Leave authentication to a thirdparty OAuth provider". This seems like adding a lot of overhead and complexity for a rather simple application, and it may not be desireable to delegate authentication and authorization to a third party.

"Use JWT". If I am correct, then the use of JWT token is not suitable for external use (like in a SPA).

"Use a combination of opaque tokens externally and JWT internally linked in a redis/memchache". This seems like the best solution for my given situation, but my problem here is the lack of actual references to libraries/code examples.

I would higly appriciate if someone had some references of actual implementations to what i am trying to accomplish which would be: Authentication, role-based authorization, in a microservice architecture.

enter image description here

Upvotes: 3

Views: 1800

Answers (1)

Anunay
Anunay

Reputation: 1903

There is not enough information to suggest what exactly should you be doing with architecture wrt authentication and authorization but I can tell you one of the approach that I tend to rely on.

Follow OAuth, as it gives you quite a few option, you can start with your own IDM/IAM and can later connect via social platforms.

We started of with JWT and for most part it was just a signed token (some time later we moved to signed and encrypted tokens). We created one service responsible for handling authentication and creating the JWT token. (We started with Keycloak but later moved to own service as keycloak was lil bulky for our use case)

When you say external, I am not sure what you mean by that, if is just accessible to end user IMO we can live with just a signed token. Yes all the information is visible to the user, but that is all his info and some authorization related information.

If you are passing your token to someone outside your boundaries, to an actual external system, where you do not want to share use information you can think of encrypting it, but then there will quite a lot of things that you need to think from security perspective and therefore going for either a standard security platform or a third party provider (whom both of you can trust and who puts enough thought in securing it) can help you in the long run.

Using the combination of an opaque token and JWT may be an overkill, unless you have a very strong reason against it. IMO you keep it simple to start with, make use of JWT through out, if required encrypt it. All you need will be one more service to manage authentication and creating and signing a token and you should be good.

Upvotes: 2

Related Questions