1 00:00:00,330 --> 00:00:08,730 Like we are discussing in the previous lecture, we can use the authorization code to grant ploa exactly 2 00:00:08,970 --> 00:00:16,590 like we discussed for the public facing client like single page applications, Web applications, native 3 00:00:16,590 --> 00:00:22,170 applications, because they can distort the claim to secret anywhere. 4 00:00:22,320 --> 00:00:29,880 The reason is anyone can decompile and check the source code of these applications easily with the help 5 00:00:29,880 --> 00:00:33,420 of browser and other tools that we have available. 6 00:00:33,720 --> 00:00:40,980 So far, these public facing claims, we have a a different flavor of operation called flow. 7 00:00:41,370 --> 00:00:44,580 It will work exactly like Operation Court Flow. 8 00:00:44,790 --> 00:00:53,040 But instead of using blank to secret, we use a mechanism pixy, which means Brufsky for court exchange. 9 00:00:53,340 --> 00:01:00,870 So there are very minor difference between pixy attraction called flow and normal alteration called 10 00:01:00,870 --> 00:01:02,940 grand flow that we discussed previously. 11 00:01:03,120 --> 00:01:07,950 So Bekesi enhanced atrisco called Flow will use the following step. 12 00:01:08,160 --> 00:01:16,710 The very first one is when user clicks login client app creates a cryptographically random code verifier 13 00:01:17,070 --> 00:01:23,220 like it will generate a random value by leveraging some encryption algorithm. 14 00:01:23,580 --> 00:01:26,670 We call that random value as code, verify it. 15 00:01:27,000 --> 00:01:33,030 And from these random value, it will again generate a different value card for the challenge. 16 00:01:33,390 --> 00:01:39,600 So during the first interaction with the alteration software, my client application will only share 17 00:01:39,600 --> 00:01:46,560 the code challenge, but it will not share the randomly generated code verified because using quarter 18 00:01:46,560 --> 00:01:51,480 verified, only you can validate a court challenge is valid or not. 19 00:01:51,810 --> 00:01:56,700 So my code verifier is indirectly acting as a client secret. 20 00:01:56,880 --> 00:02:04,050 Instead of having a dedicated client secret, that will remain always same in this approach, my client 21 00:02:04,050 --> 00:02:07,490 application will generate every time a random code verify. 22 00:02:07,770 --> 00:02:15,360 So once my code challenge is passed to the operation software and my user will enter his credentials. 23 00:02:15,570 --> 00:02:22,640 And if his credentials are correct and proper, my operation southwestward the court challenge that 24 00:02:22,660 --> 00:02:28,560 shared by my client application and redirect the user along with the authorization code. 25 00:02:28,920 --> 00:02:36,150 Once my client app receives the authorization code, this time when it's trying to get an access token 26 00:02:36,150 --> 00:02:37,020 from the key clock. 27 00:02:37,020 --> 00:02:38,710 So what are any orzo? 28 00:02:39,300 --> 00:02:45,900 Along with the authorization code, it will also pass the code, verify that it intially generated in 29 00:02:45,900 --> 00:02:46,620 the step one. 30 00:02:46,920 --> 00:02:55,130 Now, my key clock server will try to check the validity of my code challenge by using the core to verify 31 00:02:55,200 --> 00:02:58,950 which is the key for all these cryptographic operations. 32 00:02:59,250 --> 00:03:06,690 So with the help of my core to verify if my geek like server is able to matches the code challenge provider, 33 00:03:06,930 --> 00:03:12,690 then Michy Glock's, our our observer will return with an access token. 34 00:03:12,870 --> 00:03:20,460 So this way, indirectly, without the need of dedicated claim to secret claim to Web applications, 35 00:03:20,760 --> 00:03:27,720 they can maintain the authorization code ground floor using the Bixi method approach. 36 00:03:28,140 --> 00:03:35,850 The reason why we have to incorporate core verified and court challenge is suppose a hacker trying to 37 00:03:36,240 --> 00:03:40,320 intercept that request after we received the authorization call. 38 00:03:40,710 --> 00:03:48,720 So if we try to send authorization code to the key squad to get an access token, he need the word generator 39 00:03:48,720 --> 00:03:56,340 quarter verified, which is being stored under local stories are browser cookie and the client Web application. 40 00:03:56,610 --> 00:04:00,900 And that really my hacker don't know what is that random value. 41 00:04:01,050 --> 00:04:05,400 So due to that reason, the operation code will be useless for him. 42 00:04:05,640 --> 00:04:12,690 Only the application, which originally invokes the geek locks, were able to get an authorization code. 43 00:04:12,930 --> 00:04:20,250 It can only try to get an access token by passing code, verify any other persons who are trying to 44 00:04:20,430 --> 00:04:22,019 intercept in between. 45 00:04:22,230 --> 00:04:28,980 They can't get any value from the clerk server because they don't have what Ginal called verify for 46 00:04:28,980 --> 00:04:32,580 the court challenge that was initially shared to that key clock server. 47 00:04:32,940 --> 00:04:36,690 So this is the representation of that to Code Florida Pixy method. 48 00:04:37,110 --> 00:04:42,630 So as you know, first user will let public client that I want to access my resource server. 49 00:04:42,780 --> 00:04:49,650 So my client application will try to pass the court challenge and my Ozair will throw a login page to 50 00:04:49,650 --> 00:04:52,740 the user after user enter his credentials. 51 00:04:52,740 --> 00:04:57,660 And if it is a valid, my observer will return the authorization code. 52 00:04:57,900 --> 00:04:59,280 So now in the. 53 00:04:59,620 --> 00:05:05,620 A step when I'm trying to get an access token, my client application, along with the operation call 54 00:05:05,860 --> 00:05:10,930 it should also pass the court to verify that it intially generated at the step three. 55 00:05:11,200 --> 00:05:18,580 So if my court verified and court challenge they both are matching with each other, then only my operation 56 00:05:18,580 --> 00:05:21,910 server will give you access token to the user. 57 00:05:22,270 --> 00:05:30,010 So this way we can implement authorization code grant flow without the need of maintaining clanged secret 58 00:05:30,010 --> 00:05:30,490 inside. 59 00:05:30,490 --> 00:05:32,620 Are you why web applications? 60 00:05:32,920 --> 00:05:33,400 Thank you. 61 00:05:33,400 --> 00:05:35,110 And I'll see you in that next lecture by.