In the previous video, we have looked at the user detailed interface and we understand user details
is a contract or schema, a blueprint, whatever we call maintained by the spring security framework
to represent an actual user who is trying to access our application.
We also saw if there is a scenario where you are good to go with the default implementation provided
by the spring framework itself, then go ahead and use the user class, which implements this user details
interface and how all the implementation of these abstract methods.
Now in this video, let's try to see the other second important interface inside the spring security
user management, that is user details service.
So this user details that we have a single abstract method, which is low user by user.
So let's go and see the code inside the framework.
What is the under this interface?
If we see now we are inside the interface user details service, which is present inside the Spring
Security Library with the package or Jidda Spring Framework, DOT Security Code dot user.
And as we discussed, in theory, it has only one abstract method, which is not user by user name.
And the return type of that is our user details interface.
So this is the interface where we have to implement and provide our own concrete code inside this law,
user by user name, to indicate spring security.
How I want to bring my user details using a user name, you may ask, like, why can't we query directly
with the user name password and authorities into the database?
But that's a very bad practice because we should always query with only user name so that we don't have
to send the password details to the repository layer, which will eventually go to the database.
That was so there might be a scenario where DBAs can check the query logs and see what queries has been
running on the server.
To avoid such scenarios, we only pass user name to this method and this really try to have a logic
of pulling the user details based upon user name, either from a database or from a memory location
or from an election.
So once we had those user details available, spring security can be saved by having the password that
it is received from the database and what it is receiving from you.
So by comparing using password encoder, which will be discussing in the future videos, it will decide
whether the logged in user is a valid user or not.
And at the same time, you can see the authentication provider will call this interface.
If we can recollect our spring security internal architecture, we felt it is a provider which will
give you responsibility of finding and validating the user to both user detailed service and password.
And obviously this user details service interface again leverages user details, schema to validate
the user along with the password.
And similarly, the same thing is happening here in our authentication provider will leverage this user
details to call law user by user name wherever it has been implemented, which will return user details.
So with this, we understand that user detail service is a way of representing to the spring security
and how I should fetch my user details based upon user name.
But this will be very apt in the scenarios where you always want to fetch the details from the user,
but you never have a scenario of creating, updating, deleting and changing the passwords.
So for all such scenarios, we should go and implement user details manager, which we are going to
discuss in the next section.
Thank you.