Hi! I have thought about this issue, and I believe that the current solution lacks expandability.
The main problem with BEARER authentication is that unlike other standard authentication schemes, there is no way to simply specify the authentication information. For BASIC/DIGEST the username/password 's lifetime is practically infinite. Kerberos has a standard way for refreshing tokens via the token cache, which is part of the implementation. However, several protocols use BEARER auth, often with lifetimes shorter than the typical Avatica connection, and we have to handle this somehow. The patch includes FileBearerTokenProvider, which is one concrete way of implementing this. The problem is that this patch does provide for a generic solution, for example for implementing OAUTH 2.0. My proposal: - Expose the classname of the BearerTokenProvider directly, so that users can add their own implementations to the classpath - Add some mechanism to configure the provided bearerTokenProvider Something like "...;authentication=BEARER;bearer_token_provider_class=StringProvider;bearer_token_provider_arg=<token_string>" "...;authentication=BEARER;bearer_token_provider_class=FileProvider;bearer_token_provider_arg=file:///path_to_token_file" We don't really know how the user wants to configure its provider, it may use an external config file, or it may want to provide an authorization server, a user id, and some kind of secret. In theory, the user could encode its parameters into a single String that we provide for. Alternatively, since the user is already providing an external class, it is possible for the user to set up a static config for the provider before creating the connection. It could also use avatica_user to look up the configuration internally. I am not sure how sophisticated we should make the parameter handling: - Single parameter - Fixed number of parameters (probably 1-5) - an URL style list of parameters - pass unkown parameters via config. I don't remember the specifics of how Avatica handles those now. "...;authentication=BEARER;bearer_token_provider_class=SsoProvider;bearer_token_provider_arg= https://url_to_sso_provider|username|password|auth_key" "...;authentication=BEARER;bearer_token_provider_class=SsoProvider;bearer_token_provider_arg_1= https://url_to_sso_provider ;bearer_token_provider_arg_2=|username;bearer_token_provider_arg_3=password;bearer_token_provider_arg_4=auth_key" "...;authentication=BEARER;bearer_token_provider_class=SsoProvider;bearer_token_provider_arg= https://url_to_sso_provider ;bearer_token_provider_arg=username;bearer_token_provider_arg=password;bearer_token_provider_arg=auth_key" "...;authentication=BEARER;bearer_token_provider_class=SsoProvider;bearer_token_provider_arg= https://url_to_sso_provider ;arbitrary_username_key=username;arbitrary_sso_password=password;arbitrary_sso_key=auth_key" regards Istvan On Thu, Nov 30, 2023 at 1:18 PM Áron Attila Mészáros < [email protected]> wrote: > Hi everyone, > > I've opened a jira regarding the addition of Bearer authentication support > to Avatica [https://issues.apache.org/jira/browse/CALCITE-6135]. > This feature would enable authentication with bearer tokens as defined > in RFC 6750 [https://datatracker.ietf.org/doc/html/rfc6750]. > > I've also opened a PR with a proposed implementation [ > https://github.com/apache/calcite-avatica/pull/232]. Worth noting that > there is an upcoming support for this auth scheme in HttpClient as well [ > > https://github.com/apache/httpcomponents-client/commit/95e8abbda8d6af34c62c131ce0fad867d8ed0fcb > ]. > Taking this into consideration, the relevant classes are adjusted so a > future version upgrade should not be too difficult. Additionally, this > implementation provides greater flexibility with a file based token > provider allowing token refresh, however, a constant token provider class > is also implemented based on Istvan's suggestion. > > I welcome any feedback or suggestions you may have. > > Regards, > Áron > -- *István Tóth* | Sr. Staff Software Engineer *Email*: [email protected] cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------ ------------------------------
