1 00:00:00,330 --> 00:00:07,020 In this section, we will discuss a lot about what the framework, which is the most standard and common 2 00:00:07,020 --> 00:00:11,730 authentication and attribution framework followed by many organizations. 3 00:00:11,880 --> 00:00:19,440 So before we understand what the framework works and how strong security framework will help us in adopting 4 00:00:19,440 --> 00:00:24,690 the ought to framework, let's try to spend a few minutes on understanding what are the most common 5 00:00:24,690 --> 00:00:31,740 problems that Watto is trying to solve in the authentication and authorization flows inside any application. 6 00:00:31,800 --> 00:00:38,340 The very first and most common scenario that ought to framework is trying to solve is the sharing of 7 00:00:38,340 --> 00:00:45,120 the credentials of the user or the network and necessarily can be stopped by using what the framework 8 00:00:45,120 --> 00:00:45,840 efficiently. 9 00:00:46,020 --> 00:00:52,870 If you use history to be basic authentication between client and backend interactions, we may ended 10 00:00:52,890 --> 00:00:58,500 up sharing the credentials again and again over the network for each and every request that you are 11 00:00:58,500 --> 00:01:00,360 going to make to the backend. 12 00:01:00,390 --> 00:01:06,930 And at the same time, this will also force the backend application to execute the authentication, 13 00:01:06,930 --> 00:01:11,010 logic and necessary for each and every request coming from the client. 14 00:01:11,010 --> 00:01:16,920 And most importantly, we ended up sharing the client credentials or the network unnecessarily each 15 00:01:16,920 --> 00:01:19,350 and every request between the client and the source. 16 00:01:19,560 --> 00:01:27,210 So these kind of issues can be avoided by leveraging the tokens like JWT artificialities that we have 17 00:01:27,210 --> 00:01:29,120 looked in the previous sections. 18 00:01:29,250 --> 00:01:36,470 Similarly, what the framework also leverages the token based authentication where the user are requested 19 00:01:36,480 --> 00:01:39,660 to enter the credentials only during the initial login. 20 00:01:39,900 --> 00:01:47,130 But later on, they don't have to enter our credentials every time to back into the what the framework 21 00:01:47,340 --> 00:01:53,790 will leverage the token based ID or tradition to make sure that we don't have to share the credentials 22 00:01:53,790 --> 00:01:55,920 every time between the client and the server. 23 00:01:56,040 --> 00:02:02,010 Moving on to the scenario to where what the framework is trying to solve is think of a scenario where 24 00:02:02,370 --> 00:02:09,210 mine is a bank application is maintaining three different independent applications, like four different 25 00:02:09,210 --> 00:02:11,890 apartment loans cards, an account. 26 00:02:12,240 --> 00:02:18,210 So in this scenario for your end customer is common for all these three applications under the following 27 00:02:18,210 --> 00:02:19,170 two approaches. 28 00:02:19,200 --> 00:02:25,810 One is you will ask your customer to register separately in all these three applications, either with 29 00:02:25,810 --> 00:02:28,170 the different credentials or same credentials. 30 00:02:28,320 --> 00:02:34,590 And as such scenarios, you ended up maintaining the authentication and authorization logic in three 31 00:02:34,590 --> 00:02:42,300 different applications and storing the client related credentials information in three different databases. 32 00:02:42,300 --> 00:02:49,920 At Max, you can avoid serving the credentials in multiple databases and you may follow saving them 33 00:02:49,920 --> 00:02:52,440 in a single database, even in such scenarios. 34 00:02:52,450 --> 00:03:00,390 Also, your applications will now duplicate logic defined in all of them, whether it might be authentication, 35 00:03:00,390 --> 00:03:02,940 flow, authorization, floor security standards. 36 00:03:03,090 --> 00:03:06,540 So everything will get duplicated in all these applications. 37 00:03:06,540 --> 00:03:13,980 So all framework also help you in these kind of scenarios by adopting a common authorization somewhere 38 00:03:13,980 --> 00:03:15,990 inside your applications. 39 00:03:16,200 --> 00:03:23,400 That means all your authentication and authorization flows will be kept separately in a different tower, 40 00:03:23,580 --> 00:03:31,080 and that server will be leveraged whenever we try to authenticate and authorize inside any of the application 41 00:03:31,080 --> 00:03:32,740 used by the organization. 42 00:03:33,030 --> 00:03:38,550 Similarly, the last scenario that what the framework is trying to solve is think of a scenario where 43 00:03:38,820 --> 00:03:46,230 you want to use as an user an application called treat analyzer, which is built by a startup toward 44 00:03:46,230 --> 00:03:46,710 the street. 45 00:03:46,710 --> 00:03:52,270 Unless the application will do is it will try to analyze all my tweets, Rita. 46 00:03:52,320 --> 00:03:59,360 It likes comments that I am putting inside my Twitter account and give some statistics to me, but do 47 00:03:59,370 --> 00:04:00,300 not use that. 48 00:04:00,630 --> 00:04:08,340 If my tweet analyzer is not using the auto framework, they will ask me my Twitter credentials to enter 49 00:04:08,340 --> 00:04:09,780 inside their application. 50 00:04:10,050 --> 00:04:16,380 I will ended up entering my actual Tutera conventions, which will be used by Twitter analyzer. 51 00:04:16,420 --> 00:04:21,950 Have to interact with the actual Twitter to get my tweets information from them. 52 00:04:22,140 --> 00:04:29,250 But again, here we have a very serious problem, which is I'm sharing my credentials, Twitter credentials 53 00:04:29,460 --> 00:04:33,520 to tweet and laser app, which is a serious security concern. 54 00:04:33,690 --> 00:04:37,050 What if Twitter laser app misuses my credentials? 55 00:04:37,230 --> 00:04:41,690 What if they do it on my behalf using the back and APIs of the Twitter? 56 00:04:41,910 --> 00:04:46,770 So all these kind of scenarios can be avoided by following the law to framework. 57 00:04:46,950 --> 00:04:52,170 And again, we have any number of scenarios that will get solved by what framework. 58 00:04:52,380 --> 00:04:58,920 And you can see in the coming lectures how beautifully the auto framework is built, especially to answer 59 00:04:58,920 --> 00:04:59,850 our requirements. 60 00:05:00,220 --> 00:05:06,100 Related to authentication and authorization, I hope you understand what the most common problems that 61 00:05:06,100 --> 00:05:09,340 we face during that authentication and authorization flow. 62 00:05:09,610 --> 00:05:14,900 Now let's try to understand the basic details of what the framework in the next lecture. 63 00:05:15,070 --> 00:05:15,520 Thank you. 64 00:05:15,520 --> 00:05:16,870 And see you in the next room by.