For google stuff these are relevant when trying to invoke e.g. Cloud
Run services. I'm not at all knowledgeable enough with OAuth to be able
to tell if what I'm doing here is correct.
This is a breaking change. `AccessToken` got renamed to just `Token`
(since it now encompasses more than just `access_token` and there are
some changes to the `TokenInfo` type too.
Sponsored by: standard.ai
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.
Verify that a second refresh can happen after the first. This adds
coverage to ensure that a refresh flow keeps the refresh token intact by
showing that a second refresh can succeed.
What was previously called Token is now TokenInfo and is merely an
internal implementation detail. The publicly visible type is now called
AccessToken and differs from TokenInfo by not including the refresh
token. This makes it a smaller type for users to pass around as well as
reducing the ways that a refresh token may be leaked. Since the
Authenticator is responsible for refreshing the tokens there isn't any
reason users should need to concern themselves with refresh tokens.
