Status

Current state: Under Discussion

Discussion thread: here

Voting thread: here

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

When a client communicates with OIDC provider to retrieve an access token, section 2.3.1 of RFC-6749 says that clientID and clientSecret must be URL-encoded in the authorization header. The implementation of AuthenticateCallbackHandler introduced in the KIP-768 does not URL-encode clientID and clientSecret. Consequently, this may lead to authentication failure for some clients.

It seems that in practice not all OIDC providers adhere to this requirement. Additionally, clientID and clientSecret typically do not contain special characters that require URL encoding. This likely explains why this issue hasn't been reported yet.

I'm proposing to introduce a new configuration option that will allow clients to URL-encode clientID and clientSecret in the authorization header.

Public Interfaces

This change introduces a new client configuration option named `sasl.oauthbearer.header.urlencode`. It is described in the next section.

Proposed Changes

This KIP proposes adding a new configuration option named `sasl.oauthbearer.header.urlencode`. When this option is set to true, clientID and clientSecret in the authorization header will be URL-encoded. The default value is set to false for backward compatibility. 

Compatibility, Deprecation, and Migration Plan

The default behavior for any existing and new users will not change. Only users who explicitly set the new option to true would be affected by this proposal.

Test Plan

I think implementing a couple of simple unit tests would be enough.

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.