Hi Doğuşcan, Thanks for your vote!
Currently, the usage of TLS depends on the protocol used by the authorization server which is configured through the "sasl.oauthbearer.token.endpoint.url" option. So, if the URL address uses simple http (not https) then secrets will be transmitted in plaintext. I think it's possible to enforce using only https but I think any production-grade authorization server uses https anyway and maybe users may want to test using http in the dev environment. Thanks, On Thu, Mar 21, 2024 at 3:56 PM Doğuşcan Namal <namal.dogus...@gmail.com> wrote: > Hi Nelson, thanks for the KIP. > > From the RFC: > ``` > The authorization server MUST require the use of TLS as described in > Section 1.6 when sending requests using password authentication. > ``` > > I believe we already have an enforcement for OAuth to be enabled only in > SSLChannel but would be good to double check. Sending secrets over > plaintext is a security bad practice :) > > +1 (non-binding) from me. > > On Tue, 19 Mar 2024 at 16:00, Nelson B. <bachmanity...@gmail.com> wrote: > > > Hi all, > > > > I would like to start a vote on KIP-1025 > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1025%3A+Optionally+URL-encode+clientID+and+clientSecret+in+authorization+header > > >, > > which would optionally URL-encode clientID and clientSecret in the > > authorization header. > > > > I feel like all possible issues have been addressed in the discussion > > thread. > > > > Thanks, > > >
