1 00:00:00,210 --> 00:00:05,970 In the previous lecture, we discussed about what the different components involved in any or to floor 2 00:00:06,150 --> 00:00:11,160 and at the same time we also discussed there are five different grant types. 3 00:00:11,160 --> 00:00:14,880 Are outflows involved inside what framework? 4 00:00:15,000 --> 00:00:21,480 And based upon the scenario that we want to follow inside our application, we can choose one of these 5 00:00:21,480 --> 00:00:25,050 Kranti based upon security requirements. 6 00:00:25,290 --> 00:00:31,650 When I say ground floor or what floor, that means these are the floor, that authorization. 7 00:00:31,660 --> 00:00:39,870 So our client and resource servers, they follow in order to generate tokens, valid tokens and interact 8 00:00:39,870 --> 00:00:40,800 with each other. 9 00:00:41,070 --> 00:00:45,860 So in this lecture, let's try to see the first Grunty, which is authorization code. 10 00:00:46,110 --> 00:00:53,220 You can see this is the high level floor that will happen inside the authorization code, grant type 11 00:00:53,220 --> 00:00:54,390 or two floor. 12 00:00:54,690 --> 00:00:58,800 This is very similar to what we have done on the Stack overflow website. 13 00:00:59,070 --> 00:01:06,990 Comparing to that scenario, I can see I'm a user and the resource former client is the stack overflow 14 00:01:07,010 --> 00:01:11,030 website observer and the server is the Google. 15 00:01:11,340 --> 00:01:18,970 So first, as a user, I will go to the client website and I will say I want to sign up or login into 16 00:01:18,970 --> 00:01:25,130 your application and you can leverage my resources which are staying in the Google resource. 17 00:01:25,140 --> 00:01:29,980 So like last name my email to let me into your application. 18 00:01:30,150 --> 00:01:39,360 So then client our stack overflow website, they will say, OK, you tell the server of the Google that 19 00:01:39,360 --> 00:01:44,010 you are okay to share the credentials and I'll redirect them to the login page. 20 00:01:44,250 --> 00:01:49,370 You have to enter your Gmail credentials and prove your identity. 21 00:01:49,560 --> 00:01:57,130 So that's what will happen in step three, where I'll be related to the observer of the Google and I 22 00:01:57,150 --> 00:01:58,770 have to enter my credentials. 23 00:01:59,100 --> 00:02:05,640 Once I enter my credentials, the Observer will give you an authorization code to the client. 24 00:02:05,640 --> 00:02:09,650 Please remember, authorization code is not the access token. 25 00:02:09,810 --> 00:02:11,160 We are not Tejinder. 26 00:02:11,160 --> 00:02:18,690 The access token now in the next step, which is to file claim, will make a request again, this time 27 00:02:18,690 --> 00:02:27,060 in the back, and by taking the authorization code to the Google, also saying that it seems the user 28 00:02:27,210 --> 00:02:28,440 brought his identity. 29 00:02:28,440 --> 00:02:31,320 And this is the authorization code that I have received from you. 30 00:02:31,530 --> 00:02:37,560 I want to generate the access token for that user based upon the authorization code that you have shared. 31 00:02:37,800 --> 00:02:42,900 So then again, Observer will validate the attribution code that it previously shared. 32 00:02:43,020 --> 00:02:48,450 And if everything is valid, it will give you a token in step six to the client. 33 00:02:48,660 --> 00:02:55,830 Once client has the token in its hand, it will directly call the resource over in the back end. 34 00:02:56,160 --> 00:02:59,520 Like I want to access the resources of so-and-so user. 35 00:02:59,730 --> 00:03:02,820 And this is the access token that I received from the ATO. 36 00:03:03,120 --> 00:03:10,800 Now resource server will internally validate with what is this token is really valid that you shared 37 00:03:10,800 --> 00:03:11,460 to the client. 38 00:03:11,610 --> 00:03:18,450 If both resources were an observer agrees like this is a valid token and it does not expire in the last 39 00:03:18,450 --> 00:03:26,100 step, that is also will give the protected resources to the client, which in this case my last name, 40 00:03:26,100 --> 00:03:28,350 first name email to that stack go through. 41 00:03:28,710 --> 00:03:36,210 So with this the flow will complete and I'll be able to log into the stack overflow website or any client 42 00:03:36,210 --> 00:03:42,870 application you can see in the back and particularly in step two and three, where client is making 43 00:03:42,870 --> 00:03:44,250 a request to the Observer. 44 00:03:44,250 --> 00:03:51,510 Initially, it has to send the following important details in order to generate a authorization code. 45 00:03:51,630 --> 00:03:53,210 The first one is Client Eighty. 46 00:03:53,370 --> 00:04:00,690 If we can recall client ID is the idea which generated for each and every application whenever someone 47 00:04:00,690 --> 00:04:04,950 registered themselves in the Google or GitHub or Facebook. 48 00:04:05,140 --> 00:04:12,750 I can go to Google website and I can say I want to leverage your Gmail login inside my website and I 49 00:04:12,750 --> 00:04:17,519 can register by providing whatever details that they are asking me. 50 00:04:17,730 --> 00:04:18,180 Poster. 51 00:04:18,279 --> 00:04:22,820 They will give me a client along with the client credentials like client secret. 52 00:04:23,010 --> 00:04:28,650 So in the step two and three, I'll just pass a client to prove OK, I belong to Stack Overflow. 53 00:04:28,770 --> 00:04:31,560 I want to make a request to your Google ads over. 54 00:04:31,710 --> 00:04:39,390 And next is the redirect you want to redirect your is a value which the ad server will redirect once 55 00:04:39,390 --> 00:04:41,940 the login of the user is successful. 56 00:04:42,120 --> 00:04:48,930 If we have mentioned some value during the registration of the client initially, then Ottawa will make 57 00:04:48,930 --> 00:04:51,360 sure to direct to the default value. 58 00:04:51,480 --> 00:04:54,960 If you don't mention this redirect, you arrive at each and every request. 59 00:04:55,110 --> 00:04:59,900 Next scope is similar to authorities like we are requesting the Odzala. 60 00:05:00,410 --> 00:05:07,340 I want to get access to a gun with a scope like read or write, based upon the scope that we are sharing, 61 00:05:07,550 --> 00:05:12,810 the observer will decide whether I want to generate a token for this client or not. 62 00:05:12,860 --> 00:05:20,390 Next step is a value which is used to avoid of attacks by generating a token at the client. 63 00:05:20,660 --> 00:05:23,400 So you can expect the same value coming from also. 64 00:05:23,870 --> 00:05:30,370 And it's also that we make sure that no one interpreter requests and no one tampered the request. 65 00:05:30,560 --> 00:05:37,430 And at last, we also should send response time with the value call, which indicates that the observer 66 00:05:37,790 --> 00:05:45,940 that inside or do we want to follow the authorization code granted now that services response drive 67 00:05:45,950 --> 00:05:50,120 with the value code to understand or get this client application? 68 00:05:50,330 --> 00:05:54,620 They want the authorization code and they were following the authorization code. 69 00:05:54,620 --> 00:05:55,010 Correct. 70 00:05:55,310 --> 00:06:01,910 So once we send all these details in step two and three and get the authorization code in step four, 71 00:06:01,910 --> 00:06:08,210 as you can see again in step five, you were client after receiving the authorization quote from Ottawa, 72 00:06:08,480 --> 00:06:14,730 they will again make a request to the Observer for a token belong to that particular user. 73 00:06:15,080 --> 00:06:17,700 So this time they have to send code. 74 00:06:18,010 --> 00:06:23,010 Code is the value that we received in the above steps like operation code value. 75 00:06:23,510 --> 00:06:30,830 Next in this client, 80 unclaimed secret along with the client, I should also send the client secret, 76 00:06:31,070 --> 00:06:39,170 which is like my password to the Observer to prove, OK, I'm the original stack overflow for whom initially 77 00:06:39,170 --> 00:06:42,160 Google issued a clean, tidy and clean cigarette. 78 00:06:42,440 --> 00:06:48,380 If this client I clean secret are wrong, obviously Google come to know this request is not coming from 79 00:06:48,380 --> 00:06:51,110 the stack overflow and they will deny the request. 80 00:06:51,350 --> 00:06:57,840 And the last two are LeGrande type and redirect to redirect you what you already know that we are discussing 81 00:06:57,840 --> 00:07:05,480 the top and grant with the value attribution call like we have to indicate to our observer, which granted 82 00:07:05,480 --> 00:07:12,530 that we want to follow and we are mentioning Operation Code, which identifies that we are following 83 00:07:12,530 --> 00:07:15,270 alteration for granted inside our flow. 84 00:07:15,800 --> 00:07:22,160 So once these values are sent in the file by the client, that token will be issued by the Observer. 85 00:07:22,730 --> 00:07:29,450 You might have observed that in order to get the access to open, the client made a request to observe 86 00:07:29,450 --> 00:07:38,210 what two times one is initially with only client and redirecting the user to that Google login page. 87 00:07:38,330 --> 00:07:42,200 And in that step we get the alteration code from the Observer. 88 00:07:42,620 --> 00:07:51,410 Next, by taking this Operation Call client again made a request to the Observer with both attrition 89 00:07:51,680 --> 00:07:53,630 code and client credentials. 90 00:07:53,840 --> 00:07:57,940 And this time I will get the access token from the ATO. 91 00:07:58,310 --> 00:08:00,800 You may ask like, why do we need two different step? 92 00:08:00,800 --> 00:08:07,130 Why can't we to both of them in a single step, like in a single step, I can send my client credentials. 93 00:08:07,370 --> 00:08:09,110 I can then redirect. 94 00:08:09,110 --> 00:08:16,700 You are everything scop CSR token and I can redirect the user to login page of Gmail and I can get the 95 00:08:16,700 --> 00:08:18,080 access token in a single step. 96 00:08:18,410 --> 00:08:22,640 Yes, I will also agree that we can achieve this in a single step. 97 00:08:22,910 --> 00:08:30,230 But the reason why we follow two different steps in operation code grant type is it will provide you 98 00:08:30,230 --> 00:08:32,690 more security in the very first step. 99 00:08:32,900 --> 00:08:40,250 First iteration server will validate whether the user, the resource owner who is providing credentials 100 00:08:40,250 --> 00:08:44,990 on it login page is also a valid user resource. 101 00:08:44,990 --> 00:08:53,180 Whether or not if he's a valid resource Worner it will generate the automation core to the client. 102 00:08:53,360 --> 00:09:01,250 And in the next step, client has to prove its own identity by providing client credentials and attrition 103 00:09:01,250 --> 00:09:03,400 call in order to get the access token. 104 00:09:03,650 --> 00:09:13,880 So this way we have two level of security in this flow and we also have implicit grant type where these 105 00:09:13,880 --> 00:09:20,840 two steps are clamped into a single step and we don't have that attrition code in between directly within 106 00:09:20,840 --> 00:09:28,160 a single step, we get the access token from the observer, but these days no alteration. 107 00:09:28,160 --> 00:09:30,300 So we're like big organizations. 108 00:09:30,530 --> 00:09:37,100 They are encouraging us to use the implicit grant type, which has only one step further. 109 00:09:37,100 --> 00:09:43,190 They want everyone to follow the authorization code grant type due to the security issues. 110 00:09:43,440 --> 00:09:50,870 That's why if we have it, strong reason why you have to go implicit grant, then only go otherwise. 111 00:09:51,080 --> 00:09:55,070 Please use the authorization code grant type only with this. 112 00:09:55,070 --> 00:09:59,870 I'm assuming you understand what is a code grant type inside all. 113 00:10:00,110 --> 00:10:08,090 To flow, how the navigation, our request and response will flow during authentication and authorization 114 00:10:08,090 --> 00:10:08,440 flow. 115 00:10:08,810 --> 00:10:09,400 Thank you. 116 00:10:09,560 --> 00:10:14,480 And I'll see you in the next lecture where we discuss about the implicit guarantee.