An oauth2 client implementation providing the Device, Installed and Service Account flows.

I'm sending this at the risk of overwhelming as I recognize it's a pretty large pull request. This started with moving to std::future::Future as discussed in #111 then snowballed into a variety of changes (hopefully improvements) that could be made while we were already breaking semver compatibility.

Feel free to pick and choose which commits you like. The first commit is the only one necessary to get to std::future::Futures. As mentioned in the feature request this currently pins a few crates that are released with alpha labels. I would expect to wait for those dependencies to no longer be in alpha before releasing these changes.

This is highly optional, but also isn't really complicated (just calling an HTTP endpoint without much more authentication/authorization fuss): https://cloud.google.com/compute/docs/storing-retrieving-metadata.

I'm glad about feedback on this, as it's vendor-proprietary; on the other hand, it doesn't restrict the other functionality.

@dermesser

We use ServiceAccountAccess with Arc<RwLock<_>> for share between threads. But we can't it because build method returns impl GetToken in 3.1.x later.

There is a workaround?

googles python api has that as an option. very convenient as the auth URL doesn't have to be copied from terminal, especially with the installed-app-flow no copy/paste needed, ever.

this is a quickhack showing it works in rust too. I guess you might want to make this optional somehow? Please let me know how to integrate this for your library.

In many instances the libraries based on yup_oauth2 will take the Authenticator by value. This, however, prevents reuse of the tokens between different libraries or even instances of whatever type represents some sort of behaviour of a single library.

It seems like the primary reason Authenticator currently cannot be Clone is its implementation of Storage, which internally stores a Mutex<HashMap<_, _>>. A trivial solution would be to wrap that into an Arc, however, using some lock-free thread-safe storage would likely be a more lasting solution.

Hey so I tried to use this on MacOS and ran into the typical rust openssl include error. This was fixed in openssl 0.9.4. I figured updating yup-oauth2 would help others that run into a similar issue.

This adjusts the code and documentation for --all-features and --no-default-features to work correctly. With --no-default-features no DefaultAuthenticator is made available. Users are in control of picking the Connector they want to use, and are not forced to stomach a dependency on rustls or hyper-tls if their TLS implementation of choice doesn't happen to match one of the two.

To indicate this, the unstable doc_cfg feature is used to build documentation on docs.rs. That way the generated documentation has notices on these types that look as such:

This is supported on crate features hyper-rustls or hyper-tls only.

Additionally this functionality is tested via additional coverage in the Actions' CI.

This, I believe, should be a backwards compatible change, with a very small exception – users who have RUSTDOCFLAGS='--cfg=yup_oauth2_docsrs' set and are building with a non-nightly compiler will observe failures to generate documentation.

Related to: https://github.com/dermesser/yup-oauth2/issues/145

Allow users to build their own token storage system by implementing the TokenStorage trait. This allows use of more secure storage mechanisms like OS keychains, encrypted files, or secret-management tools.

Custom storage providers are Box-ed to avoid adding more generics to the API — the indirection cost will only apply if using a custom store.

I've added anyhow to allow easy handling of a wide range of errors from custom storage providers.

As discussed in the linked issue, this approach uses boxing to extend the existing storage enum and minimise API changes.

The one significant API change is that Storage.set and thus Authenticator.token() now require &mut self, so caller will need to store the Authenticator with in a mutable variable.

DiskTokenStorage is a TokenStorage that stores its tokens in a JSON file on disk. That file can be read in later, and the tokens in it reused. (The idea for using a cache file is from here: https://developers.google.com/drive/v3/web/quickstart/go#step_3_set_up_the_sample)

I am building a small app that does many things in Google Cloud. You can imagine it uses multiple scopes at the same time.

Right now, in order to authenticate against a set of scopes - I can use your lib to get the necessary token.

Now, google-apis-rs targets scopes one-by-one, for every call it makes. Which means that TokenStorage in yup-auth2 can't find them as it uses hashing of token scopes.

I would like to inquire if there is any particular reason this method is used and whether a pull request fixing this would make sense.

Using programmatic_auth as auth_uri it failes to generate a correct URL.

redirect_uri and response_type aren't allowed but they get added using FlowType::InstalledInteractive.

Google says Parameter not allowed for this message type: redirect_uri and Parameter not allowed for this message type: response_type

also the scopes need to be devided by a + instead of spaces.

After that it would be nice to get the code which is in the cookie "oauth_token".

This is needed for generating the correct token for using the hangouts chat api (see hangups). Idea is to do automatic logins/auths. 100% from CLI

Did I miss something?

Hi @dermesser is there an example on how to add a custom redirect URI? I'm using the example from the custom flow and I realized that the token never gets to the URI, because of the HTTPredirect method.

According to google's docs [1], the ADC strategy is

1. env variable
2. user credentials
3. metadata server

Currently, this crate does 1 and 3; this PR inserts 2 in there.

[1] https://cloud.google.com/docs/authentication/application-default-credentials

Note that this is a breaking change, and it also breaks the test for me locally because I have user credentials configured. Presumably the CI doesn't so I guess they'll succeed there? But this isn't great so I've marked it as a draft.

I was wondering if there was a reason for why the 2 structs and their methods, e.g. load_from_file, are not public?

https://github.com/dermesser/yup-oauth2/blob/78b79cf92cf71fd183fbe07fb44a2f29529a49b0/src/storage.rs#L185-L351

Because, from the way I read the code, I could reuse it to write my own TokenStorage implementation and keep the same json-token-format as the one used by this library without having to re-implement the code

https://github.com/dermesser/yup-oauth2/blob/78b79cf92cf71fd183fbe07fb44a2f29529a49b0/src/storage.rs#L116-L124

Is there something I am missing or not understanding?

I've been poking around trying to write a local emulator testing scheme for some code against the firestore and pubsub emulators. As others have seen in google-apis-rs (https://github.com/Byron/google-apis-rs/discussions/313) authenticators are a required part of the structure.

From what I can see https://github.com/dermesser/yup-oauth2/blob/dcc35ac2e027c66bd1f5dfc192dfdaa68d17f364/src/authenticator.rs#L688-L694 has a fixed set of authentication flows and no trait that I could implement and allow for some sort of "EmptyAuthFlow" to be passed in.

Is there any mechanism I'm missing where I could pass an authentication flow that doesn't actually request anything from a server or is it something where upstream should be allowing a "no authentication" flow and bypassing yup-oauth?

When using the InstanceMetadata authentication, the default hyper client only enforces https, and the call to the metadata server fails (returning the following error: Token retrieval failed with error: error trying to connect: Unsupported scheme http)

My current solution is to simply create a custom client as seen below:

    match yup_oauth2::ApplicationDefaultCredentialsAuthenticator::with_client(
        opts,
        hyper::Client::builder().build(
            hyper_rustls::HttpsConnectorBuilder::new()
                .with_native_roots()
                .https_or_http()
                .enable_http1()
                .enable_http2()
                .build(),
        ),
    )
    .await
    {
        yup_oauth2::authenticator::ApplicationDefaultCredentialsTypes::InstanceMetadata(
            auth_builder,
        ) => {
            Ok(auth_builder.build().unwrap())
        }
        yup_oauth2::authenticator::ApplicationDefaultCredentialsTypes::ServiceAccount(auth_builder) => {
            Ok(auth_builder.build().await.unwrap())
            }
    }

Would it be possible to make rustls an optional dependency? I'm not sure how to get around a couple of security warnings for ring https://github.com/briansmith/ring/issues/1463, which is used by rustls.

It looks like the only direct dependency is in service_account.rs:

https://github.com/dermesser/yup-oauth2/blob/ac0e5f606a9506ad6792ef3991ae6f1f8ed408b4/src/service_account.rs#L20-L25

That was written long before pks8 library started. May be it can be used instead of rustls directly. https://docs.rs/pkcs8/

Does that conceptually make sense?