For the first, Thank you for such a good article!
There is one interest issue that I trying to resolve.
With Centralized Authorization Microservice (with API Gateway) this is nice.
It can get token ( session id from client request header), validate it with redis stored data and so on. And of course, this centralized microservice is able to check if a client authenticated. But what to do with Authorization (Checking permissions) ?
Signin microservice can authenticate a user, store token to redis ,etc ....
Centralized Authorization microservice can check/validate client sessionId ( token ), OK!
But then, when getting forward to a "ABC Microservice", how to handle permissions check (authorize client) ?
Option: 1
Each microservice should receive token with permissions from middleware authorization microservice and handle Authorization of Permissions by himself.
Option: 2
Each microservice can send a gRPC request to Centralized Authorization service to handle Authorization (permissions check), etc ...
Option: 3
Each Microservice has access to Authorization service/Redis data and will handle Authorization by own functionality. In other words, there is no any middleware service.
But for all this cases we have one very big issue: How the Centralized Authorization service will know about Other services permissions ?
The /account microservice has its own permissions list.
( Developers of this microservice followed to all rules and standards to make permissions list), OK.
Question 1:
But how the Middleware Authorization microservice can know about this permissions to check ?
Question 2:
Even if account microservice sends to Authorization microservice data about own permissions list ( via gRPC) , anyways, how the Authorization microservice will know, what service should be authorized for ?
Example: Sending request to: /account/profile ...
How the Middleware microservice will know, that should check permissions for account service ?
Interest question right ?
Waiting for your answers and suggestions.
Thank you and sorry for long explanation. I tried to explain more detailed.
What I do is set a list of roles the user has access to in session data. So, when a request hits a microservice, it goes to Redis and retrieve the session data. This data contains the list of roles available for that user, and the service must know which role is the one that allows access to itself. So you just check if that role is contained in the user's role list. This way Authorization is checked at microservice level, which I think is more secure.
I am a recent graduate of computer science who is very much interested in learning how the technologies of the day work. My preference is much on the backend aspect of systems or applications.
Location
Nairobi, Kenya
Education
Jomo Kenyatta University of Agriculture and Technology
For the first, Thank you for such a good article!
There is one interest issue that I trying to resolve.
With Centralized Authorization Microservice (with API Gateway) this is nice.
It can get token ( session id from client request header), validate it with redis stored data and so on. And of course, this centralized microservice is able to check if a client authenticated. But what to do with Authorization (Checking permissions) ?
Signin microservice can authenticate a user, store token to redis ,etc ....
Centralized Authorization microservice can check/validate client sessionId ( token ), OK!
But then, when getting forward to a "ABC Microservice", how to handle permissions check (authorize client) ?
Option: 1
Each microservice should receive token with permissions from middleware authorization microservice and handle Authorization of Permissions by himself.
Option: 2
Each microservice can send a gRPC request to Centralized Authorization service to handle Authorization (permissions check), etc ...
Option: 3
Each Microservice has access to Authorization service/Redis data and will handle Authorization by own functionality. In other words, there is no any middleware service.
But for all this cases we have one very big issue: How the Centralized Authorization service will know about Other services permissions ?
i.e. Sending a request to Edit User profile data:
Microservice: account
Resource: /account/profile
Request method: PATCH
The /account microservice has its own permissions list.
( Developers of this microservice followed to all rules and standards to make permissions list), OK.
Question 1:
But how the Middleware Authorization microservice can know about this permissions to check ?
Question 2:
Even if account microservice sends to Authorization microservice data about own permissions list ( via gRPC) , anyways, how the Authorization microservice will know, what service should be authorized for ?
Example: Sending request to: /account/profile ...
How the Middleware microservice will know, that should check permissions for account service ?
Interest question right ?
Waiting for your answers and suggestions.
Thank you and sorry for long explanation. I tried to explain more detailed.
What I do is set a list of roles the user has access to in session data. So, when a request hits a microservice, it goes to Redis and retrieve the session data. This data contains the list of roles available for that user, and the service must know which role is the one that allows access to itself. So you just check if that role is contained in the user's role list. This way Authorization is checked at microservice level, which I think is more secure.
hey, good stuff. Could you have any piece of code that shows the concept you outlined in action?