1
00:00:00,330 --> 00:00:06,180
In the architecture diagram that we initially discussed at the starting of this section, we successfully

2
00:00:06,180 --> 00:00:09,810
set up the key clock also inside our locker.

3
00:00:09,870 --> 00:00:17,220
So now there can be two types of applications who want to interact with my key clock observer in order

4
00:00:17,220 --> 00:00:22,590
to get an access token or I.D. token so that they can start interacting with that resource.

5
00:00:22,590 --> 00:00:26,430
So first, let's try to construct the example of posthuman.

6
00:00:26,640 --> 00:00:35,250
So posthuman application will help us to invoke any risk apps that are deployed on resource over.

7
00:00:35,520 --> 00:00:41,190
But since Resource Somewhere is a secured, a place where all my resources are deployed, like account

8
00:00:41,190 --> 00:00:43,650
details, card details, launce details.

9
00:00:43,740 --> 00:00:46,530
So my bowsman can directly invoke.

10
00:00:46,690 --> 00:00:50,250
First, it has to get the access token from the key.

11
00:00:50,250 --> 00:00:52,570
Glock's over the same access token.

12
00:00:52,590 --> 00:00:54,890
It can go and hand over to the resource.

13
00:00:54,890 --> 00:00:57,890
So in order to get the response from that, it's also.

14
00:00:58,110 --> 00:01:05,730
So here, though, I say it is a posthuman app, but it can be any scenario where one epper trying to

15
00:01:05,730 --> 00:01:12,270
interact with other aipa, like if you construct inside the microservice network, one microservice

16
00:01:12,270 --> 00:01:15,300
may be trying to interact with the other microservice.

17
00:01:15,420 --> 00:01:18,560
So there there will be no user involved.

18
00:01:18,570 --> 00:01:25,140
It just that two systems are trying to connect with each other so that the information between them

19
00:01:25,140 --> 00:01:32,640
can be shared securely after properly authenticating and authorizing that application that is trying

20
00:01:32,640 --> 00:01:35,310
to get that data from a secure resource server.

21
00:01:35,520 --> 00:01:43,920
So if you recall our previous or two framework discussions in the scenarios where there is no user in

22
00:01:43,920 --> 00:01:49,320
Waad, we have to adopt claimed the credentials or Duflo.

23
00:01:50,580 --> 00:01:56,610
As you can see, this is the claim, the credentials grant tape that we have inside water.

24
00:01:56,760 --> 00:02:00,500
So here there is no user involved, a client application.

25
00:02:00,510 --> 00:02:05,920
It can be an microservice application trying to interact with the resource.

26
00:02:05,920 --> 00:02:07,920
So what to get the data from it.

27
00:02:08,220 --> 00:02:13,980
But since resource server is a secured application force, it will try to interact with the observer,

28
00:02:13,980 --> 00:02:17,190
saying that these are my client I.D. and Clancey.

29
00:02:17,190 --> 00:02:17,670
Correct.

30
00:02:17,820 --> 00:02:19,650
So there is no user involved.

31
00:02:19,890 --> 00:02:21,660
Please give me an access token.

32
00:02:21,900 --> 00:02:28,860
Once my observer, which is here, Keith server right at claim to credentials, it will hand over a

33
00:02:28,860 --> 00:02:30,370
token product client.

34
00:02:30,540 --> 00:02:38,280
And once the access token is given to the client, my client will try to invoke resource server directly

35
00:02:38,280 --> 00:02:41,550
with the access token to get the response from it.

36
00:02:41,820 --> 00:02:48,780
If the access token is really a valid access token, my resource server will give you a proper response

37
00:02:48,780 --> 00:02:49,590
to my client.

38
00:02:49,800 --> 00:02:54,390
So how much resource server will know whether a given access token is a valid or not?

39
00:02:54,390 --> 00:03:02,400
Is it will try to go and check with the authorization software internally to understand the value of

40
00:03:02,400 --> 00:03:03,990
that given access token.

41
00:03:04,200 --> 00:03:08,580
So now we have a clear understanding what is client credentials granted.

42
00:03:08,820 --> 00:03:16,410
So in order to invoke my resource server stapes to get account details, card details, launce details.

43
00:03:16,530 --> 00:03:24,810
First, I need a client credentials which will help me to get an access token using that access token.

44
00:03:25,050 --> 00:03:31,470
I can invoke my securest AP is deployed on this also to get a proper response.

45
00:03:31,830 --> 00:03:36,600
So in order to create a client, you have to make sure that you are in the right riyal.

46
00:03:36,840 --> 00:03:40,740
So here you can see we are on the right trail, which is easy bandeau.

47
00:03:40,920 --> 00:03:43,350
So click on the client by default.

48
00:03:43,380 --> 00:03:48,150
There are certain clients created by the key Cluck's server for internal operations.

49
00:03:48,630 --> 00:03:54,300
But since I want to create a brand new client credentials, I need to click create.

50
00:03:54,600 --> 00:04:05,260
So here client I.D., I can use as easy bank API since this client is used only for API to API invocation.

51
00:04:05,280 --> 00:04:08,910
I'm giving the client name as easy bank API.

52
00:04:09,180 --> 00:04:15,510
So the client protocol obviously has to be open and reconnect, which is built on top of WATO framework.

53
00:04:15,750 --> 00:04:16,920
So I am clicking sale.

54
00:04:17,130 --> 00:04:22,500
So once my client is created, you can see the client name is displayed on the top.

55
00:04:22,710 --> 00:04:27,330
If you want, you can again go to clients and look for the easy bank API.

56
00:04:27,570 --> 00:04:28,170
So here.

57
00:04:28,200 --> 00:04:29,640
The client is created.

58
00:04:29,820 --> 00:04:34,740
But in order to know the secret of my client, our credentials are for my client.

59
00:04:35,010 --> 00:04:37,740
First, I have to provide details about my client.

60
00:04:37,890 --> 00:04:41,210
So as you know, there are many grant type flows inside.

61
00:04:41,220 --> 00:04:42,330
What framework?

62
00:04:42,540 --> 00:04:47,100
The very standard grantee flow is authorization code flow.

63
00:04:47,430 --> 00:04:53,910
But here, since there is no user involved, we can disable the standard flow, which is authorization

64
00:04:53,910 --> 00:04:54,540
code flow.

65
00:04:54,660 --> 00:04:59,610
If you go around the question mark, it will clearly show this is the authorization code floor.

66
00:04:59,790 --> 00:05:03,570
But since there is no user involved, I'm just turning it off.

67
00:05:03,630 --> 00:05:06,940
Similarly, implicit flaw also involve the user.

68
00:05:06,960 --> 00:05:14,810
So let it be simple and direct access grant also involves user, because this is the resource one up

69
00:05:15,060 --> 00:05:17,760
credentials directly hand over to the client.

70
00:05:17,790 --> 00:05:20,970
But here, since there is no resource Wawona, there is no user.

71
00:05:21,270 --> 00:05:28,940
We can disable this also select access type as confidential, because our client will maintain claim

72
00:05:28,960 --> 00:05:30,490
daily and claim secret.

73
00:05:30,510 --> 00:05:37,980
It is not like open to public only who has access to client secret, then only they can use blind application

74
00:05:37,980 --> 00:05:42,060
detail and invoke the key Block Sarwari APIs to get the access token.

75
00:05:42,300 --> 00:05:48,690
So once they change to confidential, you can see I got one more option, which is service accounts

76
00:05:48,690 --> 00:05:49,230
enable.

77
00:05:49,440 --> 00:05:55,950
So here service accounts enable supports, client credentials grant, which means there are two service

78
00:05:55,950 --> 00:05:59,610
accounts, like one API is trying to interact with the other API.

79
00:05:59,910 --> 00:06:02,460
But this is the perfect flow that we want to follow.

80
00:06:02,670 --> 00:06:04,080
So let's make it on.

81
00:06:04,290 --> 00:06:08,520
Once we make those changes, scroll down and click sale.

82
00:06:09,000 --> 00:06:13,350
As soon as you click save, there will be a credentials tab that comes on the top.

83
00:06:13,590 --> 00:06:19,960
So if you see, this is the secret that your client should use whenever they're trying to interact with

84
00:06:19,960 --> 00:06:25,500
the key clock server for an access token to my client, Bayley's Easy Bank API.

85
00:06:25,500 --> 00:06:26,850
And the secret is this one.

86
00:06:27,060 --> 00:06:30,990
So if you want to regenerate, you can click, which will give you a new secret ID.

87
00:06:31,470 --> 00:06:39,780
So this way, we successfully set up a client that can be used in the client credentials, Grant Titlo.

88
00:06:40,050 --> 00:06:47,310
So let's try to set up the resource server in the next lecture so that we can make it all this together.

89
00:06:47,310 --> 00:06:50,150
Work to get the access token.

90
00:06:50,230 --> 00:06:57,070
And pass that to resource our and resource our can validate with that orzo and provided a proper response

91
00:06:57,070 --> 00:06:58,960
to that boatsman application.

92
00:06:59,200 --> 00:06:59,680
Thank you.

93
00:06:59,680 --> 00:07:01,450
And I'll see you in the next lecture by.