Hello Pulsar Community, Pulsar's current AuthenticationProvider interface only exposes synchronous methods for authenticating a connection. To date, this has been sufficient because we have not had any providers that rely on network calls. However, in looking at the OAuth2.0 spec, there are some cases where network calls are necessary to verify a token. As a prerequisite to adding an OAuth2.0 AuthenticationProvider, I propose the addition of asynchronous methods to the AuthenticationProvider interface. The implementation would very closely follow that of the AuthorizationProvider interface, which has both synchronous and asynchronous method declarations. It would also require refactoring any code that invokes the interface's "authenticate" method.
Note that the "authenticate" method from the AuthenticationProvider is called from a Netty thread and that a synchronous network call would block that Netty thread, which we want to avoid at all costs. (Thank you to Lari Hotari for pointing out this potential issue and its severity to me in a separate conversation.) The introduction of async methods would allow for a correct OAuth2.0 implementation without blocking any Netty threads. For reference, the OAuth2.0 spec defines a process for retrieving Authorization Server Metadata from authorization servers here in RFC-8414: https://datatracker.ietf.org/doc/html/rfc8414#section-3. In the OpenID Connect spec, which is an implementation and extension of the OAuth2.0 spec, there is an additional network call required to retrieve the Public Key from an authorization server at its `jwks_uri`. Here is a reference to the spec where it briefly mentions the network call: https://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys If there is support and interest in this idea, I am happy to put together a PIP and implement the change, once the PIP is accepted. I'd also like to note that there is already a draft PR ( https://github.com/apache/pulsar/pull/11794) proposing a new authentication provider that would retrieve JSON Web Key sets from a configured URI. This proposal would impact that PR, as it proposes making a network call in the AuthenticationProvider's authenticate method. Thanks, Michael Marshall
