Open joelossher opened 4 hours ago
Thanks for this report, @joelossher. I agree that this should be taken care of.
My primary concern is that there are applications like yours that are self-encoding already (like you are). To start encoding by default at this point would break those applications.
Because there is a constructor that accepts a RestOperations
instance, there is already a workaround, should the fix cause any issues; we just don't want to break folks in a point release.
For that reason, I'll schedule this fix for 6.5.
Are you able to provide a PR to add the encoding and a test?
Describe the bug Both the
SpringOpaqueTokenIntrospector
andNimbusOpaqueTokenIntrospector
use theclientId
andclientSecret
to authenticate the calls to the authorization server.This is done via basic authentication added using a
BasicAuthenticationInterceptor
. This does not perform any URL encoding.This issue was addressed in https://github.com/spring-projects/spring-security/issues/9610 for the token granting client, but persists for the introspection client.
The workaround at the moment is to manually encode the secret when instantiating the introspector.
To Reproduce
badSecret%
SpringOpaqueTokenIntrospector
orNimbusOpaqueTokenIntrospector
to use that clientinvalid_request
error and see the following cause in the logs:Expected behavior The token introspector should URL encode the secret.