Your Authorization Server is acting as a session manager, which is how it was done in the old applications. In modern microservices architecture, the clients get a JWT from the Authentication Server, which may also authorize the user on some permissions. The JWT is then passed on to the resource services, which internally only verifies if the token is valid and not expired. The resource services do not go to any other service for authorization. Yeah, for revoked tokens, the resource services may maintain a small cache of revoked tokens that will be expired in a while.
Sure! And Resource service should accept only a token, validate it and continue the process without accessing to any other microservice to do some verification and so on. It is why microservices pattern requires to built it dedicated.
I almost wrote this in the comments but see someone already saw this.. yes, the step where "customer service" is going to "auth service" with API token is not right. the API token should have the list of "scope" of what user can do or cannot do. Cust service can read that and decide to either respond with 200 OK and the data, OR deny the request with 403.
If possible, request you to take a screen shot of this video and post it on any of the platform, be it LinkedIn or Twitter, tagging me so that others also come to know about this video! My socials are in the description.
I think the gateway should be taking care of authorization instead of delegating that task to each called service. This can be achieved through security config filters, once authorized, the request would be passed to tge concerned service by gateway.
@@SPS_Tech he has a point If I am not wrong, if verification happens at gateway level, then Microservices can directly be accessed without access token also Validation cannot be made both in gateway and Resource server
How you will handle permissions checking for each microservice ? Assuming, each microservice has own access permissions and of course, that will not included into token. Let's explain :)
3:40,why customer service has to call auth server to confirm the token is valid? if it is a signed token, based on the roles and claims it can trust the access token right?
Become the logic to verify the JWT token doesn't live on the customer service, it lives on the auth server, in other words, the customer service doesn't know how to use the token, soo it calls the auth service to verify the token against the keys and claims
@@combinedprogrammer2477 thabks for the reply, correct me if I am wrong. Token will have all the details like who signed the token, and it will have hash of the details. If u have publick key of the token u can just verify the signature whether it is correct or not. If the token is tampered u will reject. For this u dont need to call other service right?
@@yesubabu2880 Okay let's imagine a scenario where user just got banned right?, and the client side still has the token which contains this information, now if they send a request to the customer service, and the customer service just performs the check of integrity, this is not enough to allow the user to use the requested resource, because they might have just got banned in the auth service, but the customer service doesn't know, which means the customer service needs to check with the auth service each time for it verify the token, also you assumed that they are using asymetric encryption (public and private key) but image if there was one secret key, you would have to start sharing it between the services and duplicate the logic on each service
@@combinedprogrammer2477 they will be very short lived right? Like 5 mins? As per my learning u will have to get the new token based on refresh + auth token at client side to user manager token and the new auth tokens will have max 5 mins valid time. In micro services world those tokens always shortlived roght?
Not unless they are communication with other services. The RabbitMQ is generally under the same VPC as the services so authentication wise we are good!!!!
Why will resources service go to Authorization server for validation. This is not in the flow i suppose. You must be clear in this regard sir ji. Kindly clear this in the video. You Jwt flow video of 1minute is not matching with this Authorization flow video.
If possible, request you to take a screen shot of this video and post it on any of the platform, be it LinkedIn or Twitter, tagging me so that others also come to know about this video! My socials are in the description.
If possible, request you to take a screen shot of this video and post it on any of the platform, be it LinkedIn or Twitter, tagging me so that others also come to know about this video! My socials are in the description.
Best youtube channel for java developers
baji or video banao ...we need video like this keep going
I will try my best
Your Authorization Server is acting as a session manager, which is how it was done in the old applications. In modern microservices architecture, the clients get a JWT from the Authentication Server, which may also authorize the user on some permissions. The JWT is then passed on to the resource services, which internally only verifies if the token is valid and not expired. The resource services do not go to any other service for authorization. Yeah, for revoked tokens, the resource services may maintain a small cache of revoked tokens that will be expired in a while.
Yeah that’s a perfectly valid point. But the resource service needs to have the public key so as to be able the verify the signature of the jwt token.
Sure! And Resource service should accept only a token, validate it and continue the process without accessing to any other microservice to do some verification and so on. It is why microservices pattern requires to built it dedicated.
I almost wrote this in the comments but see someone already saw this.. yes, the step where "customer service" is going to "auth service" with API token is not right. the API token should have the list of "scope" of what user can do or cannot do. Cust service can read that and decide to either respond with 200 OK and the data, OR deny the request with 403.
So, authN service would return Jwt token - which is the only thing needed for further services to detect authenticated and authorised user ? Right ?
informative
Really greatful to watch ur videos, why the architecture of securing is like that is cleared firstly with ur key points. thanku so much sir ji :)
Thanks a ton
Amazing paji ❤
Really very good explanation,easy to understand
Glad you liked it
Very good good informations
Thanks!!!!
Nice
Very interesting
Thanks a lot for your response !
Very Nice.
Thank you! Cheers!
Hi Can you provide resources on microservices authentication and authorization?
Can we have example code ?
nice explanation !!
Thanks for your comment! Do subscribe to our channel for more such videos!
If possible, request you to take a screen shot of this video and post it on any of the platform, be it LinkedIn or Twitter, tagging me so that others also come to know about this video! My socials are in the description.
I think the gateway should be taking care of authorization instead of delegating that task to each called service. This can be achieved through security config filters, once authorized, the request would be passed to tge concerned service by gateway.
That a valid point. Thanks. But where do you think the jwt validation should happen? Should it still be at the Api gateway or the individual service ?
@@SPS_Tech he has a point If I am not wrong, if verification happens at gateway level, then Microservices can directly be accessed without access token also Validation cannot be made both in gateway and Resource server
@@darkzero4608 Please watch the updated version:- ua-cam.com/video/nt892hMFWTY/v-deo.html
@@darkzero4608 Please watch the updated version:- ua-cam.com/video/nt892hMFWTY/v-deo.html
How you will handle permissions checking for each microservice ?
Assuming, each microservice has own access permissions and of course, that will not included into token.
Let's explain :)
An updated video with permissions checking has been uploaded. Do check out:- ua-cam.com/video/nt892hMFWTY/v-deo.html Thanks
if the token is stolen by the hacker and he mock the request with same token he can getthe response right? How we avoid that
We have a different kind of security called Cross Site Scripting for it!
3:40,why customer service has to call auth server to confirm the token is valid? if it is a signed token, based on the roles and claims it can trust the access token right?
Become the logic to verify the JWT token doesn't live on the customer service, it lives on the auth server, in other words, the customer service doesn't know how to use the token, soo it calls the auth service to verify the token against the keys and claims
@@combinedprogrammer2477 thabks for the reply, correct me if I am wrong. Token will have all the details like who signed the token, and it will have hash of the details. If u have publick key of the token u can just verify the signature whether it is correct or not. If the token is tampered u will reject. For this u dont need to call other service right?
@@yesubabu2880 Okay let's imagine a scenario where user just got banned right?, and the client side still has the token which contains this information, now if they send a request to the customer service, and the customer service just performs the check of integrity, this is not enough to allow the user to use the requested resource, because they might have just got banned in the auth service, but the customer service doesn't know, which means the customer service needs to check with the auth service each time for it verify the token, also you assumed that they are using asymetric encryption (public and private key) but image if there was one secret key, you would have to start sharing it between the services and duplicate the logic on each service
@@combinedprogrammer2477 they will be very short lived right? Like 5 mins? As per my learning u will have to get the new token based on refresh + auth token at client side to user manager token and the new auth tokens will have max 5 mins valid time. In micro services world those tokens always shortlived roght?
And thanks for patiently replaying!!
Does this apply to Rabit MQ-based console background services?
Not unless they are communication with other services. The RabbitMQ is generally under the same VPC as the services so authentication wise we are good!!!!
Why will resources service go to Authorization server for validation. This is not in the flow i suppose. You must be clear in this regard sir ji. Kindly clear this in the video. You Jwt flow video of 1minute is not matching with this Authorization flow video.
That one is an updated version. Please find a detailed video on it in my channel !
@@SPS_Tech Thank you.
nice explanation .. make coding video
If possible, request you to take a screen shot of this video and post it on any of the platform, be it LinkedIn or Twitter, tagging me so that others also come to know about this video! My socials are in the description.
Sir, is Any source code available for this. Pls🙏
Will check and let you know !
If possible, request you to take a screen shot of this video and post it on any of the platform, be it LinkedIn or Twitter, tagging me so that others also come to know about this video! My socials are in the description.
I think this tutorial is kind ambiguous and misleading.
Please find the updated version here:- ua-cam.com/video/nt892hMFWTY/v-deo.html