Describe the bug
We are using https://spring.io/projects/spring-security-oauth as an oauth2 provider.
In separate projects we are then using the spring security webclient provided by this project.
We tried upgrading to Spring Boot 2.5.2 from 2.5.0, which bundled Spring Security 5.5.1 instead of 5.5.0 and noticed that our applications broke and our client authentication attempts were rejected by our oauth2 provider.
It appears that the change in e6c268a now causes both the client id and client secret to be url encoded. This means that any client secrets containing those special characters then don't work any more as the oauth2 provider doesn't url decode the client id / secret before testing them.
To Reproduce
Upgrade to Spring Security 5.5.1 with a client secret with special characters (e.g. space, quote) that will be url encoded. The basic authentication header will then be sent with the client id / secret url encoded as well as base64 encoded. This breaks oauth2 providers that aren't expecting the basic authentication header elements to be url encoded too.
Expected behavior
We expect that the client id and client secret are not url encoded before being transmitted. That is what the spring security oauth provider is expecting and is current behaviour.
https://datatracker.ietf.org/doc/html/rfc2617#section-2 specifies that the client id and secret are base64 encoded before being transmitted anyway, so it seems odd to url encode them and then base64 encode them immediately afterwards anyway.
The equivalent ticket for our oauth2 provider in spring-attic/spring-security-oauth#1826 is still open, indicating that there hasn't been a fix there for the server. Reading the comment in #9610 (comment):
applying the fix now may break existing applications that are using non-compliant providers.
which is exactly what has happened to us.
Describe the bug
We are using https://spring.io/projects/spring-security-oauth as an oauth2 provider.
In separate projects we are then using the spring security webclient provided by this project.
We tried upgrading to Spring Boot 2.5.2 from 2.5.0, which bundled Spring Security 5.5.1 instead of 5.5.0 and noticed that our applications broke and our client authentication attempts were rejected by our oauth2 provider.
It appears that the change in e6c268a now causes both the client id and client secret to be url encoded. This means that any client secrets containing those special characters then don't work any more as the oauth2 provider doesn't url decode the client id / secret before testing them.
To Reproduce
Upgrade to Spring Security 5.5.1 with a client secret with special characters (e.g. space, quote) that will be url encoded. The basic authentication header will then be sent with the client id / secret url encoded as well as base64 encoded. This breaks oauth2 providers that aren't expecting the basic authentication header elements to be url encoded too.
Expected behavior
We expect that the client id and client secret are not url encoded before being transmitted. That is what the spring security oauth provider is expecting and is current behaviour.
https://datatracker.ietf.org/doc/html/rfc2617#section-2 specifies that the client id and secret are base64 encoded before being transmitted anyway, so it seems odd to url encode them and then base64 encode them immediately afterwards anyway.
The equivalent ticket for our oauth2 provider in spring-attic/spring-security-oauth#1826 is still open, indicating that there hasn't been a fix there for the server. Reading the comment in #9610 (comment):
which is exactly what has happened to us.