DaoAuthenticationProvider

Sets the PasswordEncoder instance to be used to encode and validate passwords. If not set, the password will be compared as plain text.

For systems which are already using salted password which are encoded with a previous release, the encoder should be of type org.springframework.security.authentication.encoding.PasswordEncoder. Otherwise, the recommended approach is to use org.springframework.security.crypto.password.PasswordEncoder.

The source of salts to use when decoding passwords. null is a valid value, meaning the DaoAuthenticationProvider will present null to the relevant PasswordEncoder.

Instead, it is recommended that you use an encoder which uses a random salt and combines it with the password field. This is the default approach taken in the org.springframework.security.crypto.password package.

Allows subclasses to perform any additional checks of a returned (or cached) UserDetails for a given authentication request. Generally a subclass will at least compare the getCredentials() with a getPassword(). If custom logic is needed to compare additional properties of UserDetails and/or UsernamePasswordAuthenticationToken, these should also appear in this method.

Allows subclasses to actually retrieve the UserDetails from an implementation-specific location, with the option of throwing an AuthenticationException immediately if the presented credentials are incorrect (this is especially useful if it is necessary to bind to a resource as the user in order to obtain or generate a UserDetails).

Subclasses are not required to perform any caching, as the AbstractUserDetailsAuthenticationProvider will by default cache the UserDetails. The caching of UserDetails does present additional complexity as this means subsequent requests that rely on the cache will need to still have their credentials validated, even if the correctness of credentials was assured by subclasses adopting a binding-based strategy in this method. Accordingly it is important that subclasses either disable caching (if they want to ensure that this method is the only method that is capable of authenticating a request, as no UserDetails will ever be cached) or ensure subclasses implement additionalAuthenticationChecks(UserDetails, UsernamePasswordAuthenticationToken) to compare the credentials of a cached UserDetails with subsequent authentication requests.

Most of the time subclasses will not perform credentials inspection in this method, instead performing it in additionalAuthenticationChecks(UserDetails, UsernamePasswordAuthenticationToken) so that code related to credentials validation need not be duplicated across two methods.