Support Secure Hashed Client Secrets in OAuthRegisteredClientsStore

[nazoking]

Is your feature request related to a problem? Please describe.
Currently, the OAuthRegisteredClientsStore interface does not support storing hashed client secrets or verifying them using standard password hashing algorithms. As a result, implementations often store client secrets in plaintext and compare them directly. This is not aligned with security best practices and creates a considerable risk if the storage backend is compromised.

Describe the solution you'd like
Add a method such as verifyClientSecret(clientId: string, clientSecret: string): Promise<OAuthClientInformationFull | undefined> to the store interface. This would allow secrets to be stored hashed and checked securely. The client authentication middleware should be refactored to use this method, supporting both new secure storage and legacy plaintext secrets where needed. Documentation or migration guidance should be provided for transitioning existing implementations.

Describe alternatives you've considered

• Continuing to use getClient and maintain direct string comparisons, but this does not mitigate the mentioned security risks.
• Wrapping or extending the current interface externally for hashing support, but this leads to fragmentation and inconsistencies among implementations.

Additional context

• Algorithms like bcrypt or Argon2 are widely used for secure password and secret hashing.
• Related files: src/server/auth/middleware/clientAuth.ts, src/server/auth/clients.ts
• A clear migration or compatibility path for legacy secrets is important to avoid breaking existing deployments.

[felixweinberger]

cc @pcarleton

[pcarleton]

ideally we'll delete the client secret checking in v2 in favor of providing examples of using AS libs, like better-auth or node-oidc-provider

[minglong51]

Happy to pick this up. Per your note about dropping client-secret checking in v2 in favor of AS-library examples, I'd scope it as a new example under examples/ — wiring an external AS (better-auth or node-oidc-provider, whichever you'd prefer as the canonical one) to store and verify hashed client secrets — rather than adding verifyClientSecret() to the now-server-legacy OAuthRegisteredClientsStore.

Does that match the direction, and would examples/server/ (alongside the existing in-memory demo provider) be the right home? Happy to start once you confirm the library + placement.

[Ram9199]

I am collecting real-world incidents around MCP auth/credential handling.

Was hashed client-secret support driven by an actual leakage incident, audit finding, enterprise requirement, or deployment blocker? What changed afterward - external secret store, custom client store, separate credentials, audit logging, rotation policy, or no change?

Not asking about any product. I am trying to separate current operational pain from sensible pre-incident hardening.