William Ho 24d1d8c429 Set default expires_at if only ID token is returned
Was running into an issue where ID tokens were being used by the
authenticator even after the 1-hour validity period, and weren't being
refreshed.

After enabling debug logs, I found out that this was happening because
ID-token-only responses don't contain the `expires_in` field, so the
authenticator assumes it doesn't expire.

Interestingly, this doesn't happen when using the service account
impersonation flow, because it's explicitly handled there by defaulting
the expiration to 1 hour.

The ID token is a JWT so it's possible to decode it to get the
expiration date, but to avoid introducing a JWT decoding dependency,
I've gone for the same approach of defaulting to 1 hour, as indicated in
the GCP docs.
2023-02-17 14:25:38 -05:00
2019-02-21 20:46:00 +00:00
2022-11-23 14:46:36 -06:00
2022-11-25 07:56:08 -08:00
2015-05-08 11:41:26 +02:00
2022-12-02 21:20:26 +01:00
2017-02-03 06:55:17 +01:00
2016-01-10 21:53:51 -05:00
2021-03-04 11:46:05 +01:00
2021-02-06 22:59:00 +11:00

Build
Status codecov crates.io

yup-oauth2 is a utility library which implements several OAuth 2.0 flows. It's mainly used by google-apis-rs, to authenticate against Google services. (However, you're able to use it with raw HTTP requests as well; the flows are implemented as token sources yielding HTTP Bearer tokens). Note that the newer, asynchronous versions of this crate (version 4) are not compatible with google-apis-rs anymore/at the moment.

To use asynchronous APIs with the new yup-oauth2 (from version 4), use the async-google-apis code generator, which generates asynchronous API stubs for Google APIs and other providers who provide Discovery documents for their REST APIs. (WARNING: that project is still alpha-quality. Contributions are welcome)

The provider we have been testing the code against is also Google. However, the code itself is generic, and any OAuth provider behaving like Google will work as well. If you find one that doesn't, please let us know and/or contribute a fix!

Supported authorization types

  • Device flow (user enters code on authorization page)
  • Installed application flow (user visits URL, copies code to application, application uses code to obtain token). Used for services like GMail, Drive, ...
  • Service account flow: Non-interactive authorization of server-to-server communication based on public key cryptography. Used for services like Cloud Pubsub, Cloud Storage, ...

Usage

Please have a look at the API landing page for all the examples you will ever need.

A simple commandline program which authenticates any scope and prints token information can be found in the examples directory.

The video below shows the auth example in action. It's meant to be used as utility to record all server communication and improve protocol compliance.

usage

Versions

  • Version 1.x for Hyper versions below 12
  • Version 2.x for Hyper versions 12 and above
  • Version 3.x for historical interest
  • Version 4.x for tokio 0.2/0.3
  • Version 5.x for tokio 1.0

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Description
No description provided
Readme 996 KiB
Languages
Rust 99.2%
Shell 0.8%