Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Avoid eager PasswordEncoder initialization in ClientSecretAuthenticationProvider

Open Beginner friendly
  • Is something wrong?
#19,783 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java, spring
Domain
authentication, security

Research direction

Start in oauth2/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/authentication/ClientSecretAuthenticationProvider.java and compare its encoder initialization with core/src/main/java/org/springframework/security/authentication/dao/DaoAuthenticationProvider.java. Check PasswordEncoderFactories.createDelegatingPasswordEncoder() and SingletonSupplier usage. Done means preserving the public API and default behavior while allowing construction with a custom FIPS-compatible encoder without eagerly creating the default encoder.

Written by the indexing model from the issue text.

Description

status: waiting-for-triage type: enhancement

ClientSecretAuthenticationProvider eagerly initializes its default PasswordEncoder using PasswordEncoderFactories.createDelegatingPasswordEncoder()
in its constructor.

https://github.com/spring-projects/spring-security/blob/3d23cf3f317c685b7b75fdd7cd54cb60ee0b78cc/oauth2/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/authentication/ClientSecretAuthenticationProvider.java#L79

This factory creates legacy MessageDigestPasswordEncoder instances, including MD5. On a FIPS-compliant JDK where MD5 is unavailable, constructing ClientSecretAuthenticationProvider fails even
when a custom FIPS-compatible PasswordEncoder is configured.

https://github.com/spring-projects/spring-security/blob/3d23cf3f317c685b7b75fdd7cd54cb60ee0b78cc/crypto/src/main/java/org/springframework/security/crypto/factory/PasswordEncoderFactories.java#L78

This is similar to the issue discussed in gh-14670.

DaoAuthenticationProvider already avoids this problem by lazily initializing its default PasswordEncoder using SingletonSupplier.

https://github.com/spring-projects/spring-security/blob/3d23cf3f317c685b7b75fdd7cd54cb60ee0b78cc/core/src/main/java/org/springframework/security/authentication/dao/DaoAuthenticationProvider.java#L58

I would like to suggest to apply the same pattern to ClientSecretAuthenticationProvider, preserving the existing public API and default behavior while avoiding construction of the default encoder
when setPasswordEncoder() is used.

I would be happy to submit a PR if this approach sounds correct.

Dominant language
Java
Stars
9.6k
Forks
6.4k
Avg merge
1d 20h
Merged PRs (30d)
54

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from spring-projects/spring-security

All issues in spring-projects/spring-security

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.