1
00:00:00,270 --> 00:00:07,470
In the last few videos, we have spoke about user details, service user details, password encoders,

2
00:00:07,500 --> 00:00:15,240
user details, manager, a lot about it, and we now have an understanding in which scenarios I should

3
00:00:15,240 --> 00:00:21,510
go for user details, service and user details manager and what's the responsibility of password and

4
00:00:21,510 --> 00:00:21,830
code.

5
00:00:22,140 --> 00:00:29,250
But if you look at the spring security architecture, authentication provider is the company that leverages

6
00:00:29,400 --> 00:00:34,210
user detail services and password in order to perform the authentication.

7
00:00:34,410 --> 00:00:40,800
So in the last all videos that we have discussed, we saw that how the call will come to user detail

8
00:00:40,810 --> 00:00:47,580
service implementation like law user by username and password order will be addressed to validate the

9
00:00:47,580 --> 00:00:48,610
password returns.

10
00:00:48,900 --> 00:00:55,940
But what if we have a scenario where you don't want to go with the default way of authentication?

11
00:00:55,950 --> 00:01:01,110
Like I don't want to leave res user detail service or user details manager password.

12
00:01:01,110 --> 00:01:09,120
And I just want to write my own logic based upon my application requirement in such scenarios.

13
00:01:09,600 --> 00:01:14,310
Will do I have an option of customizing the ID provider?

14
00:01:14,910 --> 00:01:21,690
So if we see the spring security internal architecture, as soon as a request has been coming from the

15
00:01:21,780 --> 00:01:28,560
way a filter will intercept that request and it will convert that request strictly payslip request or

16
00:01:29,490 --> 00:01:36,930
request into an authentication object post that that authentication object will be given to the authentication

17
00:01:36,930 --> 00:01:37,530
manager.

18
00:01:37,740 --> 00:01:44,730
Implementation authentication manager will in turn argue that responsibility of validating the user

19
00:01:44,730 --> 00:01:52,680
to authentication provider and ID provider will take help by default from the user details service and

20
00:01:52,680 --> 00:01:54,960
password in order to validate the user.

21
00:01:55,200 --> 00:02:00,900
So this is how the default approach asking security to validate user data.

22
00:02:01,440 --> 00:02:07,170
Of course we have customized user detailed service password encoder asport requirement.

23
00:02:07,170 --> 00:02:10,979
Like I have written my code inside law user by user details.

24
00:02:11,160 --> 00:02:19,510
I also know how to customize, create user update user, delete user and how to leverage different password

25
00:02:19,510 --> 00:02:21,900
encoders that we have like Bakry password.

26
00:02:21,900 --> 00:02:25,440
And so we have done certain kind of customization.

27
00:02:25,620 --> 00:02:34,080
But still we are following the spring security schema or contract like we are not coming completely

28
00:02:34,080 --> 00:02:35,850
out of spring security contract.

29
00:02:36,180 --> 00:02:39,690
So there might be scenarios where you don't want to follow all this thing.

30
00:02:40,110 --> 00:02:48,060
You just wanted to have your way of authentication logic without adhering to this user detail service

31
00:02:48,060 --> 00:02:50,460
are password encoder, whatever you want.

32
00:02:50,700 --> 00:02:57,200
So in such scenarios, we should look at customizing authentication provider component.

33
00:02:57,810 --> 00:03:04,220
So let's try to discuss about authentication provider in detail in this section so that you will get

34
00:03:04,230 --> 00:03:11,940
a clarity once we discuss, will also enhance our application to customize authentication provider component

35
00:03:11,940 --> 00:03:13,800
also to understand about.

36
00:03:14,070 --> 00:03:15,590
Thank you and see you in the next room by.