Moving TokenSource and TokenSourceProvider to an cloud vendor agnostic crate

[nicolas-vivot]

Hi,

@yoshidan
This is not an issue but a proposal.
I would like to have your opinion on this as i believe we (the community) could all benefits from a very small change.

By the way, i have been using this library for over a year now without any problems, thank you very much for your work!

Proposal

I would like to:

• create a new lightweight and vendor agnostic crate to hold token source related types.
• move TokenSource (and probably TokenSourceProvider as well) into this crate.
• have your crates depending on it. (and hopefully the time passing by other crates too)

Motivation behind this

I have used multiple other crates (for other cloud vendors for example) that all manage somehow authentication tokens.
The recurrent pattern in such library is to go with a simple static String, or out-dated credential implementations.

There are multiple issues with this:

• ownership / source of truth in term of token store.
• cannot handle automatic refresh of expired ones.
• code duplication, maintainability burden.

This has been proven quite inefficient as we are requested to deal with token renewal that by ourselves again and again.
I am a very lazy guy, hate redoing same things for no reason and i think it's time to change that.

How the proposal can help solving this?

If we have a simple crate that owns shared definitions as Trait, then it's easy for everyone to provide their own implementation, or request something implementing those traits in their libraries.

What benefits does this bring ?

• better abstraction (easier cross library integration)
• better separation of concerns and responsibilities

Practical examples

• we can then have the google-cloud-rust crate providing providers for Google, another one for AWS, etc. As long as they all use the same trait, it is now easy to switch from one implementation to another on the user side.
• other utility crates like reqwest can rely on this to collect authentication token when preparing request. (this is actually one of my motivation, as i want to provide a middleware to do so to solve issues around token refresh in case of automatic retries)

Those are the two i can think about now, but i remember already having this idea a few months ago for another use case.

Why not depending directly on google-cloud-token?

Because it has google and cloud in the name. This would be misleading as it has nothing to do with Google, and other cloud vendors may not be willing to use for theirs?

Wrap up

I would like your opinion about this.
You have already made some simple but good Trait for this matter, so i think its fair to ask your opinion and not steal/duplicate your work on another crate.