The client secret in the database will become {bcrypt} secret when login.

[Waylon-Firework]

Step 1: register a client with {noop} secret.

mysql database

Step 2: login with oauth flow, the client secret in the database will become {bcrypt} secret.

http://localhost:9000/oauth2/authorize?response_type=code&client_id=message-client&scope=openid%20profile%20message.read&state=some-state&redirect_uri=http://127.0.0.1:8080/authorized

mysql database

[Waylon-Firework]

When login api is triggered, the sql update client will be called and the client secret will be changed from {noop} to {bcrypt}

I'm curious why it's forcing me to change to {bcrypt} when login. Is there any way to prevent it.

[shanman190]

Hi @Waylon-Firework! 👋

So I'll start with a little bit of a primer as to the feature that you're coming across here. Similar to the password upgrades that Spring Security users have come to know for end user accounts, this provides the same mechanisms for upgrading the security of the OAuth client credentials themselves. The framework uses the current encoding and strength, if applicable, to determine if the source secret that we have just confirmed is correct is in need of being upgraded. Upgraded in this context may mean changing the underlying encoding entirely or increasing the strength of the current algorithm. The way that this is triggered is by the current configured implementation of PasswordEncoder in use for your application.

Based upon what you have presented here so far, this leads me to know that the presently available PasswordEncoder in your app is the BcryptPasswordEncoder implementation. As such, the provider is interpreting that you want to upgrade the secret by changing the encoding type from noop to bcrypt with strength 10.

If you don't want for this to happen, in what I hope is your demo/testing app, then you just need to configure your application with the NoOpPasswordEncoder implementation. The NoOpPasswordEncoder implementation is for testing purposes as stated by the documentation here as it provides no secure storage of the credentials when it is at rest in the database. When this encoder encounters your secret, it will perform no actions as the encoding of the stored secret matches the current configured encoding type.

[Waylon-Firework]

Thank you @shanman190 .

I added the {noop} password encoder and it works as expected.

But I feel that this update behavior should not be the default. Because it makes our key a secret. We will have to find its original value from the sql backup. Wouldn't it be better if it could be turned on with a configuration?

[Waylon-Firework]

Anyway, it does come in handy for users who need to upgrade their security. However, it happened too suddenly. 😄

[shanman190]

Would you mind expressing how this feature in particular is causing you an issue?

From an authentication standpoint, the same secret will still be used to authenticate and would result in a successful authentication.

[Waylon-Firework]

@shanman190 Sure.

We have some external customers, we generate client_id, client_secret and limit scope for them. Customers can log in to our system, and they can see the client secret we generated for them from the page. Of course, to view it, they need to verify the email verification code.

Currently, the client secret stored in the database becomes a {bcrypt} secret when we upgrade the spring authorization server version. This prevents them from viewing the original client secret.

Moreover, as a server, we also cannot see the original secret when we upgrade the spring authorization server version, because {bcrypt} is difficult to crack. We will have to restore them from historical mysql data.

[Waylon-Firework]

@shanman190
We also have a requirement, we hope that client secret password encoder and user's password encoder can be configured separately. Because the user's password requires {bcript}

[shanman190]

So the password encoder can be configured separately for just for the OAuth piece presently via:

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/config/annotation/web/configurers/OAuth2ClientAuthenticationConfigurer.java

Line 128 in e5fcbe4

public OAuth2ClientAuthenticationConfigurer authenticationProviders(

spring-authorization-server/oauth2-authorization-server/src/main/java/org/springframework/security/oauth2/server/authorization/config/annotation/web/configurers/OAuth2AuthorizationServerConfigurer.java

Line 157 in e5fcbe4

public OAuth2AuthorizationServerConfigurer clientAuthentication(Customizer<OAuth2ClientAuthenticationConfigurer> clientAuthenticationCustomizer) {

Personally for the other part, the use case really sounds more like the OIDC Dynamic Client registration flow which provides back the client secret on the response itself. This enables secure storage without compromising on the feature of being able to show the user the secret one time.
https://docs.spring.io/spring-authorization-server/docs/current/reference/html/protocol-endpoints.html#oidc-client-registration-endpoint

[Waylon-Firework]

Thank you @shanman190 . That's great.
And for the client secret, when we go to register a google api, they will also give us a page that can be used to view the secret. I think I need to store them somewhere else. Because we really didn't expect that this would be adjusted for automatic updates. For my case, my server is a oidc provider.