DEV Community

Cover image for Authentication & Authorization in Microservices Architecture - Part I

Authentication & Authorization in Microservices Architecture - Part I

Tzachi Strugo on February 14, 2021

About Behalf Behalf facilitates in-purchase financing for B2B buyers and sellers. As a financial institution, it is critical to maintain...
Collapse
 
wparad profile image
Warren Parad

Great writeup, it's amazing how many teams still try to couple authentication to authorization. But you got that exactly right to keep these separate.

I'm also wondering about the implementation, these are usually really challenging. I've found from many past experiences that building the user IAM aspects to allows encounter some pitfalls. I actually wrote up my most recent adventure into building authz in our services.

Collapse
 
tzachis profile image
Tzachi Strugo

Thanks, Warren
Implementing and enforcing IAM isn't a trivial task and can be challenging in a microservice architecture.
We think that choosing the correct access management control depends on the application requirements and can be changed from one to another.

In the next part, we will see the implementations that feet for our needs.

I am 100% identify with your sentence: ״I've been through this journey myself, more than once. Every time, I was looking back...״

As humans, we have the nature to solve problems; Looking back and asking ourselves the questions, did we achieve our goals? What can we do otherwise? or did we choose the correct solution for that particular problem?

This step is critical while solving problems that keeping us going and improve our skills as software engineers

Collapse
 
tracker1 profile image
Michael J. Ryan

I generally include a handful of high level roles in service and application design. May also want groups. These can be included in the jwt. Authorization by ownership of of course separate.

Collapse
 
wparad profile image
Warren Parad

That works with small systems, but invariably JWTs are not designed to handle resource management. There just was never a way to support granular permissions access stored in the JWT that works at scale.

Thread Thread
 
tracker1 profile image
Michael J. Ryan

I mostly agree, you still may need fine grained permissions. But you can go a long way with roles and groups for most things.

Document ownership. Things like owner read/write, group read, manager read/write and even manager above are typical oversights.

I'm just pointing out that for many applications, rules and groups fit well enough.

Collapse
 
jorgesivil profile image
JorgeSivil

Thanks for the article!

I was thinking in that it is OK to put roles/permissions in the JWT payload, however it could become very very large, and we have to account for header limits: stackoverflow.com/questions/686217...

Even if we have low-level permissions Posts.Manage.UpdateOwn, and we can send it in the JWT payload, the data could be very large as more permissions are created, but most importantly, the Posts microservice should be able to check the business rule regarding Posts.Manage.UpdateOwn.

So we have two options here, given a request PUT /users/profile

1) In the controller, you get the User and the Post object and send them to /authorize/Posts.Manage.UpdateOwn with the Post and User object's serialized, and then you check that Post.ownerId === User.id and return true or

2) In the Posts microservice you do the following check: permissions.includes('Posts.Manage.UpdateOwn') && Post.ownerId === User.id

I think that the second one makes more sense.

Collapse
 
fandiks32 profile image
irfan

@jorgesivil How did you handle header limits?

Collapse
 
jorgesivil profile image
JorgeSivil

By setting only the necessary information (like userid) and then having an endpoint to retrieve the full list of permissions

Collapse
 
honatas profile image
Jonatas de Moraes Junior

Nice. Separating authentication from authorization is a big step. However, using JWT may not be the best approach, and I can see you already started feeling the pain given the rather big pitfalls section of your article.

I hereby invite you to take a look at this article where I describe the huge bunch of problems you will face while using JWT, and propose a more straightforward solution:

dev.to/honatas/a-different-approac...

I'm open for discussion. =)

Collapse
 
tzachis profile image
Tzachi Strugo

Hi Johatas,
Thank you for reading and sharing your thoughts. Understanding the separation of concern is critical to solving the problem of Authentication & Authorization solutions.

Indeed, stateless authentication(JWT in our case) suffers from several downsides that need to be aware of. There are pros and cons for both stateless & stateful concepts. For some use cases, the stateless approach isn't the best one.

With your permission, I would like to hold this discussion until I will publish part II :-)

Collapse
 
mnf profile image
Michael Freidgeim

What will be in part II and when it will be published?

Collapse
 
jennyfive profile image
Jen

what happened to the next article? :)

Collapse
 
alimobasheri profile image
MirAli Mobasheri

Thanks! That's a useful article, and I really enjoyed reading it. I have no experience with microservices on a large scale, but I can easily understand the concepts you have described. Using a single endpoint for authentication, although being difficult, looks like a valid and clean way of getting things in a flow.
Waiting for the next part!

Collapse
 
tracker1 profile image
Michael J. Ryan

Would add that you can use asymmetric rsa signing. This is generally safer than a shared secret. I'm fact the authority generating the jwt can share it's public key publicly.

Other considerations are revocation and renewal.

Collapse
 
jamesmuldrow profile image
James

Great write up, I've been searching for an article that breaks down authentication and authorization in a microservices environment. This article definitely helped me out. Looking forward to part II! When do you expect to release it?

Collapse
 
zvermafia profile image
Mokhirjon Naimov

I'm waiting for the second part of this article, and it will be better if you share the date when you'd like to write that part...

Collapse
 
kevinsalimi profile image
Kevin Salimi

You've really good head in describing things. Awesome!

Collapse
 
caojs profile image
caojs

Great post, seperating authentication and authorization is a right approach in microservices. What do you think if I add RBAC with domains/tenants in authentication? Example:

[PUT] /domainA/user/profile

  1. Login to authentication service and get JWT token which contains identity and user's roles in domainA
  2. Send JWT to domainA service, roles are checked in here.
Collapse
 
mehdicharife profile image
Mehdi Charife

In the example, would domainA service check for the validity of the token?

Collapse
 
amassani_90 profile image
ABDALLA MASSANI

Great article.. Just one comment - I see you have mentioned the Authentication as a cross cutting concern and hence can be implemented at the API Gateway level, however, I am not clear about the authorization piece. Are you suggesting that each Microservice manage the authorization at that level? Seems like I am missing something.

Collapse
 
anikolaienko profile image
Andrii

Nice! Thanks

Collapse
 
njmsaikat profile image
Saikat Roy

Good explanation. BTW waiting for the next part.

Collapse
 
cwgk profile image
vitonzhang

Waiting for the next article!

Collapse
 
chukwuemekaigbokwe profile image
Chukwuemeka Igbokwe

Nice article

Collapse
 
noskcire11 profile image
noskcire11

Great article. 've been wanting to ask, how do you manage unauthenticated routes for API Gateway as Global Auth service approach?

Collapse
 
anvodev profile image
An Vo

Nice article. Waiting for part 2! ^^

Collapse
 
iamimrankhan95 profile image
IMRAN AHMED KHAN

are the other parts of this post coming? :)