1
00:00:00,330 --> 00:00:07,020
Now, in this lecture, let's try to understand the Fort Grant type inside the floor, which is claimed

2
00:00:07,020 --> 00:00:07,830
declensions.

3
00:00:08,670 --> 00:00:13,980
So before diving into the details, I want to give you a scenario where we will use client grant.

4
00:00:14,430 --> 00:00:20,820
So think of a scenario where you don't have any U.A. application, where you don't have any resource.

5
00:00:20,850 --> 00:00:22,890
One are user involved.

6
00:00:23,190 --> 00:00:30,910
You have multiple backend applications, which they share data between them, like in the scenario of

7
00:00:30,960 --> 00:00:37,890
myco services, where hundreds of applications trying to interact with each other and shared some secured

8
00:00:37,890 --> 00:00:39,270
information between them.

9
00:00:39,660 --> 00:00:45,870
So in such scenarios, you decided instead of maintaining the authentication and alteration flow inside

10
00:00:45,870 --> 00:00:51,990
each and every application, you decided to keep that all the alteration, logic and authentication

11
00:00:51,990 --> 00:00:59,040
logic in a separate server called Observer and every application before it tried to communicate with

12
00:00:59,040 --> 00:01:05,310
the other application inside your organization, they have to prove their identity and get the access

13
00:01:05,310 --> 00:01:12,840
token from the observer, which will be eventually shared to the other application to get the resources

14
00:01:12,840 --> 00:01:13,350
from it.

15
00:01:13,650 --> 00:01:19,530
So in such scenarios, we will use client credentials GRANDPAP as the name indicates.

16
00:01:19,800 --> 00:01:27,420
And you can also see there is no involvement of resources or not are used in this outflow, as you can

17
00:01:27,420 --> 00:01:27,940
expect.

18
00:01:28,080 --> 00:01:35,040
This is the floor that will happen inside the client credentials granted in the very first step, client

19
00:01:35,040 --> 00:01:40,140
will directly call the Observer when, as a client, it's one of the backend application.

20
00:01:40,530 --> 00:01:47,790
Make a request to the Observer to get the access token, bypassing the client credentials like its own

21
00:01:47,790 --> 00:01:54,080
client and client credentials, which it received initially when it existed with the Observer.

22
00:01:54,480 --> 00:02:00,120
And since there are no user involvement here, there won't be any user credentials will be shared in

23
00:02:00,120 --> 00:02:06,840
the second step, where observers validate the client credentials and given access token to access their

24
00:02:07,080 --> 00:02:08,240
particular resources.

25
00:02:08,370 --> 00:02:14,400
Now, in the third step, the client will make a request to other application where it trying to get

26
00:02:14,400 --> 00:02:18,990
some protective resource, bypassing the broken IT result from the orzo.

27
00:02:19,290 --> 00:02:25,530
And at last the resource server or other backend application will validate this token by connecting

28
00:02:25,530 --> 00:02:30,870
to the observer and eventually provided the resources that client is requesting.

29
00:02:31,260 --> 00:02:37,350
Based upon our discussion in the step one, where the client is making a request to Utsav to get their

30
00:02:37,350 --> 00:02:41,660
act astrocom, it has to send the following three values in the request.

31
00:02:41,970 --> 00:02:50,700
One is the client ID and sekret to prove its identity to the ottowa like I belongs to so-and-so organization

32
00:02:50,700 --> 00:02:53,490
and these are my client credentials and client ID.

33
00:02:53,790 --> 00:02:59,110
Next, a scope similar to authorities, the level of access that client is requesting like.

34
00:02:59,400 --> 00:02:59,970
Right.

35
00:03:00,300 --> 00:03:01,630
And the last one is a grant.

36
00:03:01,980 --> 00:03:03,540
Here are the differences.

37
00:03:03,810 --> 00:03:11,310
We will send a value as client underscore credentials to indicate observer that there is no user involved

38
00:03:11,310 --> 00:03:16,290
and we want to use the client credentials grant type to generate the access token.

39
00:03:16,530 --> 00:03:21,900
And you can easily expect this is the most simplistic grant type flaw in what?

40
00:03:22,140 --> 00:03:28,830
Because we awarded one of the component, which is resource Worner are user inside this floor.

41
00:03:29,190 --> 00:03:34,590
We use this application flow of client grant type only in the scenarios.

42
00:03:34,590 --> 00:03:39,390
There is no user and you are involved and we're multiple backend application.

43
00:03:39,390 --> 00:03:44,940
They are trying to share data between them by using the backend apps like Aristocats.

44
00:03:45,270 --> 00:03:46,770
I hope it makes sense to you.

45
00:03:47,100 --> 00:03:51,420
Let's try to discuss the last grant that we have in the next lecture.

46
00:03:51,420 --> 00:03:51,900
Thank you.

47
00:03:51,900 --> 00:03:52,350
And by.