Securing #microservices using #apigateway | #authentication & #authorisation in #microservices

Your queries:-
Authentication & Authorisation in Microservices
authentication and authorization in spring boot microservices
token security microservices
token security pattern microservices
token security authentication
jwt token security
microservices security
microservices security using jwt authentication gateway
microservices security spring boot
microservices security architecture
microservices security with oauth2
microservices security patterns
Authentication in microservices
Authentication & Authorisation Microservices,securing microservices using api gateway, authentication and authorization in spring boot microservices,token security microservices,token security pattern microservices,token security authentication,jwt token security,microservices security,microservices security using jwt authentication gateway,microservices security spring boot,microservices security architecture,microservices security with oauth2,microservices security patterns,microservices security interview questions,Api gateway microservices security.
It’s very critical to provide authentication and authorization security to the microservices apps, when they communicate with each other. Mostly, microservices are exposed as REST APIs in distributed environments. REST APIs are stateless. It’s challenging to maintain client sessions with backend REST APIs. A strong API security mechanism is required to communicate between consumer and producer microservices. This API token security pattern provides a better Authentication & Authorization (A&A) service and maintains a session between client and backend REST APIs. For example, web/mobile clients connect to the API gateway first, which is a single point of entry of backend REST API microservices. The following diagram depicts how to get the API token by passing the access token to the authorization server which could be JWT/OAuth and get the API token to access backend APIs. Web/mobile clients will add this API token to the REST request call in the form of an HTTP request header and pass it to other backend services after A&A:
There are multiple open source and enterprise solutions to implement the API token security. OAuth and JavaScript Web Token (JWT) are popular, which create encrypted tokens and encrypt other information like user details, roles, and other key-value pairs. There is a provision to also add the expiry time of the API token. This token is generated by the server-side A&A service on demand. It can be added to a client’s service REST API header during the inter-microservice communication. This token is authenticated and validated for the expiry time on every request and then authorized to connect to backend business services and databases. So, with a design pattern, only authorized services can be granted access to microservices APIs. The API gateway is a recommended way to expose all backend microservices to client services like mobile, web, and other clients. It provides a single point of entry to the backend APIs. It uses this API access token internally to get access. It internally integrates with the access token API. Advantages The advantages are as follows: Secures inter-communication between microservices. Provides secure and strong encrypted authorization. Also provides user roles, which can be checked and accessed at the backend authorization service. Tokens can be encrypted with a strong encryption algorithm and expiry time.
Access token can be also created to access a new security token, if it’s expired. Use cases The use cases are as follows: User login authentication. User role authorization like admin, read only access, and so on. Use the API gateway with microservices.
What to expect: (0:00)
Why is it required? Problem and Solution!: (0:11)
Where is Token Security Pattern deployed? API Gateway: (1:50)
Basic Authentication Flow: (2:18)
When two Microservices are involved: (3:58)
Thank You: (5:43)

[@arnabchowdhury4892]

Best youtube channel for java developers

[@mohanp4059]

Nice

[@aadityasinghrana8245]

Amazing paji ❤

[@pradeeppalai]

informative

[@GurcharanSingh-fy2nw]

Very good good informations

[@SPS_Tech]

Thanks!!!!

[@mrabbas9]

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.

[@SPS_Tech]

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.

[@davida.7586]

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.

[@AbhishekJain118]

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.

[@rohanskoshti]

So, authN service would return Jwt token - which is the only thing needed for further services to detect authenticated and authorised user ? Right ?

[@deepa8177]

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 :)

[@SPS_Tech]

Thanks a ton

[@colorful_pages]

Very interesting

[@SPS_Tech]

Thanks a lot for your response !

[@devireddyfavreddy4785]

Really very good explanation,easy to understand

[@SPS_Tech]

Glad you liked it

[@MirGlobalAcademy]

Very Nice.

[@SPS_Tech]

Thank you! Cheers!

[@awstutorials1]

nice explanation !!

[@SPS_Tech]

Thanks for your comment! Do subscribe to our channel for more such videos!

[@SPS_Tech]

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.

[@nadigatlapraveen4681]

Hi Can you provide resources on microservices authentication and authorization?

[@carlandres3319]

Does this apply to Rabit MQ-based console background services?

[@SPS_Tech]

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!!!!

[@user-xt2gm9io6f]

Can we have example code ?

[@davida.7586]

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 :)

[@SPS_Tech]

An updated video with permissions checking has been uploaded. Do check out:- kzbin.info/www/bejne/pKWbamWegquKirs Thanks

[@cookies4techies992]

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

[@SPS_Tech]

We have a different kind of security called Cross Site Scripting for it!

[@vazzdoin]

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]

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 ?

[@darkzero4608]

@@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

[@SPS_Tech]

@@darkzero4608 Please watch the updated version:- kzbin.info/www/bejne/pKWbamWegquKirs

[@SPS_Tech]

@@darkzero4608 Please watch the updated version:- kzbin.info/www/bejne/pKWbamWegquKirs

[@yesubabu2880]

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?

[@combinedprogrammer2477]

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

[@yesubabu2880]

@@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?

[@combinedprogrammer2477]

@@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

[@yesubabu2880]

@@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?

[@yesubabu2880]

And thanks for patiently replaying!!

[@nitinjagannath9219]

nice explanation .. make coding video

[@SPS_Tech]

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.

[@sinafallahpour8543]

ommmmmmmm

[@SPS_Tech]

Thanks! Do subscribe to our channel for more such content!

[@SPS_Tech]

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.

[@gopinathr3043]

Sir, is Any source code available for this. Pls🙏

[@SPS_Tech]

Will check and let you know !

[@SPS_Tech]

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.

[@mohammadwazir5566]

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.

[@SPS_Tech]

That one is an updated version. Please find a detailed video on it in my channel !

[@mohammadwazir5566]

@@SPS_Tech Thank you.

[@md.mahfuzurrahman8219]

I think this tutorial is kind ambiguous and misleading.

[@SPS_Tech]

Please find the updated version here:- kzbin.info/www/bejne/pKWbamWegquKirs