support for dynamic authentication for the client

[GlenDC]

Most languages/runtimes allow by default to create a client using the known auth flow of Google.
To allow authentication in different ways in a pre-defined order, e.g.
https://docs.rs/gcp_auth/latest/gcp_auth/struct.AuthenticationManager.html#method.new also provides this.

Would it be possible to support this?
Or is this out scope and one is expected to use libraries like that in order to create a client
using credentials gathered from such external libraries?
But if so it would mean that in case I do not want to use a service key (e.g. for dev purposes) that I first need to write a tmp file?!).

Could you help me in how you see this expected flow. Might also help if this part is documented, as I find personally that info regarding authentication / client creation is a bit lacking. Which for GCloud experts might be fine, but for people who just use Gcloud occasionally it is a bit too minimal to my taste.

That being said, I hope this doesn't come over wrong and I am vary thankful to all who put their hard work into this create. It looks cool!

[lquerel]

Thanks for your feedback. I agree with you that the support of different authentication flows is currently limited in this crate. There are several gcp auth crates available to improve this situation and I'm not quite sure which one to include yet (e.g. https://crates.io/crates/gcp_auth and https://crates.io/crates/google-authz). Do you have any feedback on these two crates?
I created the following issue to follow up (#23).
PR are also welcome.

[GlenDC]

Given that I'll require decent BigQuery support for my projects to have a chance at being adopted for production use in my company I honestly can afford to put them in preparing a PR for you, which I can do in the weeks to come.

The question is, how we best approach it indeed. In this regards it is also importance that you as a maintainer fully agree with the approach going forward.

GCP Auth seems like a better choice I think compared to google-authz. But that the same time the latter does provide refreshment of tokens even though I am not sure how they plan to achieve that.

Generally speaking there are two approaches we can go in approaching this:

• either we make sure that it's easy enough to plugin a token and make clear errors indicating when a token is to be refreshed;
• we add support for one of two external crates, possibly even behind feature flags, which would handle all the token creation for the user, including the refreshing of tokens;

A combination of two approaches are possible of course as well, to allow the user to not use any of these feature flags and still use their own approach.

I'm honestly no expert in this area. Naively I had hoped that by now Google would have started provide support for Rust in their client set, but I guess I was wrong. So here we are.

And of course thanks again for your work on this crate.

Before I start doing actually research on how it might be solved "best", from the to of your head do you have any proposals from your side, given your unique POV as a maintainer of this crate.

[lquerel]

I have looked at several projects on this subject. The crate https://crates.io/crates/google-authz seems to me the most interesting to integrate.

Comments on the other alternatives:

• https://crates.io/crates/google_auth has not been updated for 1 year.
• https://crates.io/crates/gouth seems to be the previous version of google-authz.