1 00:00:00,150 --> 00:00:06,900 In the previous video, we have looked at the user detailed interface and we understand user details 2 00:00:06,900 --> 00:00:13,890 is a contract or schema, a blueprint, whatever we call maintained by the spring security framework 3 00:00:13,890 --> 00:00:19,080 to represent an actual user who is trying to access our application. 4 00:00:19,110 --> 00:00:25,650 We also saw if there is a scenario where you are good to go with the default implementation provided 5 00:00:25,650 --> 00:00:32,910 by the spring framework itself, then go ahead and use the user class, which implements this user details 6 00:00:32,910 --> 00:00:38,420 interface and how all the implementation of these abstract methods. 7 00:00:38,730 --> 00:00:46,980 Now in this video, let's try to see the other second important interface inside the spring security 8 00:00:46,980 --> 00:00:50,970 user management, that is user details service. 9 00:00:51,000 --> 00:00:57,620 So this user details that we have a single abstract method, which is low user by user. 10 00:00:57,990 --> 00:01:01,490 So let's go and see the code inside the framework. 11 00:01:01,710 --> 00:01:04,200 What is the under this interface? 12 00:01:04,330 --> 00:01:12,840 If we see now we are inside the interface user details service, which is present inside the Spring 13 00:01:12,840 --> 00:01:19,510 Security Library with the package or Jidda Spring Framework, DOT Security Code dot user. 14 00:01:20,190 --> 00:01:28,940 And as we discussed, in theory, it has only one abstract method, which is not user by user name. 15 00:01:29,130 --> 00:01:34,080 And the return type of that is our user details interface. 16 00:01:34,770 --> 00:01:43,590 So this is the interface where we have to implement and provide our own concrete code inside this law, 17 00:01:43,590 --> 00:01:47,190 user by user name, to indicate spring security. 18 00:01:47,400 --> 00:01:55,470 How I want to bring my user details using a user name, you may ask, like, why can't we query directly 19 00:01:55,590 --> 00:02:00,110 with the user name password and authorities into the database? 20 00:02:00,690 --> 00:02:09,360 But that's a very bad practice because we should always query with only user name so that we don't have 21 00:02:09,360 --> 00:02:15,780 to send the password details to the repository layer, which will eventually go to the database. 22 00:02:15,780 --> 00:02:23,310 That was so there might be a scenario where DBAs can check the query logs and see what queries has been 23 00:02:23,310 --> 00:02:24,570 running on the server. 24 00:02:24,810 --> 00:02:34,380 To avoid such scenarios, we only pass user name to this method and this really try to have a logic 25 00:02:34,380 --> 00:02:41,640 of pulling the user details based upon user name, either from a database or from a memory location 26 00:02:41,790 --> 00:02:43,170 or from an election. 27 00:02:43,530 --> 00:02:51,990 So once we had those user details available, spring security can be saved by having the password that 28 00:02:51,990 --> 00:02:56,790 it is received from the database and what it is receiving from you. 29 00:02:57,120 --> 00:03:03,900 So by comparing using password encoder, which will be discussing in the future videos, it will decide 30 00:03:04,080 --> 00:03:08,360 whether the logged in user is a valid user or not. 31 00:03:08,550 --> 00:03:15,030 And at the same time, you can see the authentication provider will call this interface. 32 00:03:15,180 --> 00:03:23,700 If we can recollect our spring security internal architecture, we felt it is a provider which will 33 00:03:23,700 --> 00:03:32,180 give you responsibility of finding and validating the user to both user detailed service and password. 34 00:03:32,190 --> 00:03:41,520 And obviously this user details service interface again leverages user details, schema to validate 35 00:03:41,520 --> 00:03:43,440 the user along with the password. 36 00:03:43,440 --> 00:03:51,240 And similarly, the same thing is happening here in our authentication provider will leverage this user 37 00:03:51,240 --> 00:04:01,100 details to call law user by user name wherever it has been implemented, which will return user details. 38 00:04:01,590 --> 00:04:09,930 So with this, we understand that user detail service is a way of representing to the spring security 39 00:04:10,140 --> 00:04:15,360 and how I should fetch my user details based upon user name. 40 00:04:15,600 --> 00:04:24,150 But this will be very apt in the scenarios where you always want to fetch the details from the user, 41 00:04:24,300 --> 00:04:31,020 but you never have a scenario of creating, updating, deleting and changing the passwords. 42 00:04:31,430 --> 00:04:38,940 So for all such scenarios, we should go and implement user details manager, which we are going to 43 00:04:38,940 --> 00:04:40,480 discuss in the next section. 44 00:04:40,650 --> 00:04:41,250 Thank you.