OAuth2AuthorizationGrantRequestEntityUtils URL encoding in secrets is causing problems with authorization

[williancolognesitrimble]

Describe the bug
Looks like the util OAuth2AuthorizationGrantRequestEntityUtils is changing the client-secret when there is "+" in the middle of the credential, for example: tav+MiE+7w if we encode it as base64 with echo -n "tav+MiE+7w" | base64 the result will be dGF2K01pRSs3dw==.
but if I call spring boot security with these credentials:
client-id: test and client-secret: tav+MiE+7w OAuth2AuthorizationGrantRequestEntityUtils will return the Authorization as Basic dGVzdDp0YXYlMkJNaUUlMkI3dw== and if you decode this base64 to string with echo -n 'dGVzdDp0YXYlMkJNaUUlMkI3dw==' | base64 --decode, the result wil be test:tav%2BMiE%2B7w%.

So, my authorization server that is also spring boot, but in the version 2.3.9 and spring security oauth2 in version 2.4.1 is not able to understand this token with %2B encoding and returning 401 in /token request.

Should it work like this?

To Reproduce
client service: spring boot 2.6.3 and spring security 5.6.2
authorization server: spring boot 2.3.9 and spring-security-oauth2 2.4.1

request client_credentials basic to authorization server using a secret with a + signal in the middle of it.

@Bean
    fun authorizedClientServiceAndManager(
        clientRegistrationRepository: ClientRegistrationRepository,
        authorizedClientService: OAuth2AuthorizedClientService
    ): AuthorizedClientServiceOAuth2AuthorizedClientManager {
        val authorizedClientProvider = OAuth2AuthorizedClientProviderBuilder.builder()
            .clientCredentials()
            .build()
        val authorizedClientManager = AuthorizedClientServiceOAuth2AuthorizedClientManager(
            clientRegistrationRepository, authorizedClientService
        )
        authorizedClientManager.setAuthorizedClientProvider(authorizedClientProvider)
        return authorizedClientManager
}

@Bean
    fun requestTokenBearerInterceptor(
        authorizedClientServiceAndManager: AuthorizedClientServiceOAuth2AuthorizedClientManager
    ): RequestInterceptor {
        val authorizeRequest = OAuth2AuthorizeRequest
            .withClientRegistrationId("test-registration")
            .principal("test-registration")
            .build()
        return RequestInterceptor { request ->
                    val authorizedClient = authorizedClientServiceAndManager.authorize(authorizeRequest)
                    authorizedClient.accessToken.tokenValue
                request.header("Authorization", "Bearer $token")
        }
}

application.yml:
spring:
  security:
    oauth2:
      client:
        registration:
          test-registration:
            client-id: test
            client-secret: tav+MiE+7w
            provider: test-registration
            authorization-grant-type: client_credentials
            client-authentication-method: basic
            scope: test
        provider:
          test-registration:
            authorization-uri: http://authorization-server/oauth/authorize
            token-uri: http://authorization-server/oauth/token
            user-info-uri: http://authorization-server/user
            user-name-attribute: login

The problem occur in authorizedClientServiceAndManager.authorize(authorizeRequest).

Expected behavior
Should convert the Authorization base64 with the same value set in application.yml without URL encoding.

[sjohnr]

Hi @williancolognesitrimble, thanks for reaching out!

Should it work like this?

Sadly, yes (though causing errors is of course not desired). This change was intentionally introduced in 5.6, per #9610 (and noted in 5.6.0-M1), which aligns us with RFC 6749, Section 2.3.1. We're aware that this spec unfortunately conflicts with RFC 2617.

Spring Security OAuth2 is non-compliant regarding this aspect of the spec. Note that spring-security-oauth2 is reaching end-of-life this May and is currently only receiving security patches. See this announcement and update. See this comment if you need help working around the issue with a non-compliant provider.

I'm going to close this as working as designed. I understand that this is a frustrating experience as you upgrade and/or encounter this issue, so please don't hesitate to ask if I can help clarify the workaround or anything else needed to get you going again. Thanks for your understanding.

[williancolognesitrimble]

Hi @williancolognesitrimble, thanks for reaching out!

Should it work like this?

Sadly, yes (though causing errors is of course not desired). This change was intentionally introduced in 5.6, per #9610 (and noted in 5.6.0-M1), which aligns us with RFC 6749, Section 2.3.1. We're aware that this spec unfortunately conflicts with RFC 2617.

Spring Security OAuth2 is non-compliant regarding this aspect of the spec. Note that spring-security-oauth2 is reaching end-of-life this May and is currently only receiving security patches. See this announcement and update. See this comment if you need help working around the issue with a non-compliant provider.

I'm going to close this as working as designed. I understand that this is a frustrating experience as you upgrade and/or encounter this issue, so please don't hesitate to ask if I can help clarify the workaround or anything else needed to get you going again. Thanks for your understanding.

No problem. just confirming, we're doing a migration to new spring and changing our auth server, and that why we found this issue.

I'm going to change the secret until everything is migrated.

Thank you for the clarifications.