In this section, we will discuss a lot about what the framework, which is the most standard and common
authentication and attribution framework followed by many organizations.
So before we understand what the framework works and how strong security framework will help us in adopting
the ought to framework, let's try to spend a few minutes on understanding what are the most common
problems that Watto is trying to solve in the authentication and authorization flows inside any application.
The very first and most common scenario that ought to framework is trying to solve is the sharing of
the credentials of the user or the network and necessarily can be stopped by using what the framework
efficiently.
If you use history to be basic authentication between client and backend interactions, we may ended
up sharing the credentials again and again over the network for each and every request that you are
going to make to the backend.
And at the same time, this will also force the backend application to execute the authentication,
logic and necessary for each and every request coming from the client.
And most importantly, we ended up sharing the client credentials or the network unnecessarily each
and every request between the client and the source.
So these kind of issues can be avoided by leveraging the tokens like JWT artificialities that we have
looked in the previous sections.
Similarly, what the framework also leverages the token based authentication where the user are requested
to enter the credentials only during the initial login.
But later on, they don't have to enter our credentials every time to back into the what the framework
will leverage the token based ID or tradition to make sure that we don't have to share the credentials
every time between the client and the server.
Moving on to the scenario to where what the framework is trying to solve is think of a scenario where
mine is a bank application is maintaining three different independent applications, like four different
apartment loans cards, an account.
So in this scenario for your end customer is common for all these three applications under the following
two approaches.
One is you will ask your customer to register separately in all these three applications, either with
the different credentials or same credentials.
And as such scenarios, you ended up maintaining the authentication and authorization logic in three
different applications and storing the client related credentials information in three different databases.
At Max, you can avoid serving the credentials in multiple databases and you may follow saving them
in a single database, even in such scenarios.
Also, your applications will now duplicate logic defined in all of them, whether it might be authentication,
flow, authorization, floor security standards.
So everything will get duplicated in all these applications.
So all framework also help you in these kind of scenarios by adopting a common authorization somewhere
inside your applications.
That means all your authentication and authorization flows will be kept separately in a different tower,
and that server will be leveraged whenever we try to authenticate and authorize inside any of the application
used by the organization.
Similarly, the last scenario that what the framework is trying to solve is think of a scenario where
you want to use as an user an application called treat analyzer, which is built by a startup toward
the street.
Unless the application will do is it will try to analyze all my tweets, Rita.
It likes comments that I am putting inside my Twitter account and give some statistics to me, but do
not use that.
If my tweet analyzer is not using the auto framework, they will ask me my Twitter credentials to enter
inside their application.
I will ended up entering my actual Tutera conventions, which will be used by Twitter analyzer.
Have to interact with the actual Twitter to get my tweets information from them.
But again, here we have a very serious problem, which is I'm sharing my credentials, Twitter credentials
to tweet and laser app, which is a serious security concern.
What if Twitter laser app misuses my credentials?
What if they do it on my behalf using the back and APIs of the Twitter?
So all these kind of scenarios can be avoided by following the law to framework.
And again, we have any number of scenarios that will get solved by what framework.
And you can see in the coming lectures how beautifully the auto framework is built, especially to answer
our requirements.
Related to authentication and authorization, I hope you understand what the most common problems that
we face during that authentication and authorization flow.
Now let's try to understand the basic details of what the framework in the next lecture.
Thank you.
And see you in the next room by.