In the previous section, we have discussed how to implement or to mechanism inside a springboard application
by leveraging Utsav what off GitHub.
Similarly, there are many authorizations that was provided by social network based companies like Facebook,
Google, Twitter.
So there are many organizations that they provide their own operation somewhere, and we can always
leverage them in order to implement security inside our Web applications.
But if you really asked me to consider same GitHub observer out, Google server, our Facebook operations
over to my Web application that I have built inside discourse like is a bank app.
It is not a great option.
The reason is all the social network based companies are any other company operation server provided
by them will only help you to authenticate and user so that only authorized users can access security
pages inside your application.
But if you want to incorporate role based access management inside a Web application, then these observers
are not a good consideration, because when you go and grab these social network based authorization
psoas, you will not have a flexibility of maintaining roles and authorities, based upon your own custom
logic, that you how you just how to adopt simple authentication so that only LogMeIn users can access
your secured pages.
But that's not my requirement in saying my easy bank application.
There are certain secured parts where admins can access and similarly users can access.
So that kind of role based authentication and authorization is what I needed.
So in order to incorporate or to login authentication and authorization inside my easy bank app, I
need to consider authorization server products like Kik lock up to forge Iraq database cognito.
So all these are the products which are focused dedicatedly to provide or to framework for complex Web
based applications.
So these products not only will help you in incorporating and implementing what framework inside Web
application, but they also provide a lot of out-of-the-box features, like where all your user details,
like your email password, the rules, everything can be stored inside these products instead of it
storing them in a database like we are doing right now.
Right now, if you can recall, our easy bank application architecture, there is an angular UI application
where the user will provide his username and password, and those credentials will be passed on to the
backend application.
And spring security will evaluate those credentials by using the values present inside that database.
And the same backend application is acting as an authorization solver and resource.
So which is not a good practice if you want to consider for enterprise applications.
So basically the main advantage of auto framework is to separate your ID and operation logic from your
business logic.
So in order to do that, you should always consider a separate authentication and authorization somewhere
under all your business logic can stay inside the resource somewhat.
So in order to add two or two framework inside my easy bank application, I'm going to consider key
clock tower and implement automation framework inside easy bank app using auto framework.
Again, the reason why I chose key clogged arteries, it is open source and it is free to use.
And once you understand how to implement or to framework inside of Web applications like easy bank app
using key observer, it is pretty much easy to adopt to commercial products that we have available inside
the market, like OK to forge Iraq and HWC Cognito.
So due to that reason, I'm considering cheak lock up server inside this section.
So let me explain you.
What we are going to implement are what kind of changes we are going to make inside our easy bank application
in order to incorporate or to framework using it locatio.
Firstly, I will have a resource server, which will strictly how the rest APIs expose in order to get
resources and data regarding accounts, costs, loans and other details.
So this resource, our our backend server will not have anything related to authentication and authorization.
So.
So I'm going to remove all database interaction to perform a login operation.
So all those authentication providers.
Password and Cortez filters everything.
I'm going to remove and my back, and so I will simply act as a resource server.
So whenever someone tries to access it by passing a valid access token, it will give a proper response.
So once I build my resource, so what next?
At the same time, I will have a separate authentication server based upon geek clock.
So inside these key block authentication server, I will store all my user credentials.
The rules so that I can perform authentication and authorization using key Gloc Ottowa.
So this way, we separated both authentication, authorization, logic and the business logic into two
separate entities.
And with that in place, we can have two different kind of applications who are trying to interact with
the resource over.
One is you may try to connect to your resource, our using client applications like angular based Web
applications, just like how we are doing right now.
So in this scenario, my Angular app application will try to get a access token by connecting with the
key block whatsoever and passing credentials to get.
Once my Osawa use an access token in the second step, it will go and pass that access token to the
resource server, and it will try to invoke any API that is exposed by the resource.
So like accounts, loans are cards.
And once my resource server receives an access token, it will go and validate whether the access token
is valid or not by connecting the dots over.
And at last, if the access token provided by client application is valid, my resource server will
respond with the data that my client application is expecting.
The same kind of flow will also happen if you try to consume.
The AP is exposed by a resource server through Posman Application or any other backend application which
is trying to consume APIs, expose by the resource server.
So this way, regardless of what application is trying to connect with the resource.
So they have to follow that all these four steps.
The very first one is they have to connect to the key block, whatever, to get access token.
And the second step is the same access token needs to be passed to the resource server while client
application trying to consume the APIs exposed by that resource.
So once the resource server validate the access token with the ATSO, it will respond with the successful
response that my client application is expecting.
So these are the simple four steps.
But don't worry that this seems to be a complicated process.
We will implement this step by step.
And I can assure you, it's very simple.
By the end of this section, you will be very confident on how to implement this kind of war to framework
inside any Web application.
Thank you.
And I'll see you in that next lecture.
Right.