Client secret double encoding issue when updating an existing registered client

[ghost]

Avoid client secret double encoding when updating a registered client

Closes gh-389

[ghost]

hi @jgrandja. When 10273 will be released in the spring-security project the implementation will no longer be valid as the prefix and suffix can be changed => checking for { } to determine if it's already encoded is not enough, we must use the same prefix/suffix that is used in DelegatingPasswordEncoder

[jgrandja]

Hi @ovidiupopa91. I realized shortly after I proposed the fix that it wasn't a robust solution and that we needed an alternative solution. And yes, 10273 just validated that.

I'm catching up with things this week after returning from PTO so please give me until next week to propose a more robust solution. I'll also review your other PR later next week. Thanks.

[jgrandja]

Hi @ovidiupopa91. This fix is a bit tricky. However, there is one easy fix that can be applied in order to avoid the double encoding.

We currently don't allow updates for id, client_id and client_id_issued_at. We could also disable updates for client_secret and client_secret_expires_at. This would at least resolve the double encoding, which is the main issue we need to address.

I realize this limits the update capabilities, but applications can still customize based on their requirements. We might have to revisit this at a later point but I would say let's go with disabling updates for client_secret and client_secret_expires_at.

[ghost]

Hi @jgrandja . Ok, I will rollback to the initial state and I will remove client_secret and client_secret_expires_at from the update statement.

[jgrandja]

Thanks for the updates @ovidiupopa91 ! This is now in main.
FYI, I added minor polish to the test.
Thanks!

[Shabin]

Hi, is there any plan for allowing the update of client_secret_expires_at? I have a requirement to extend the client validity.