Currently this library uses curl to perform HTTP requests. It'd be nice if we could add an async API that supports the tokio event loop. I'm not sure if it's possible with the curl bindings but it will allow us to use the async/await syntax in the future.

This is the tracking Issue for Release 4

ToDo

• [x] Remove future-1 support
• [x] Remove reqwest 0.9 support
• [x] Switching from http1 to http2
• [x] Replace rust-crypto
• [x] Switch to rusttls by default #100
• [x] Replace failure #90
• [x] Switch to default-features = false in openidconnet-rs
• [x] Token Introspection #97

In 8.2 the spec allows for adding arbitrary, vendor-specific (or as described in 11.2, getting them registered) parameters for both requests and responses. As an example, in my case I'm working with OIDC, which is built on top of OAuth2, which makes use of this by using an extra id_token field in the response for a JWT token. Would providing support for extra fields (not OIDC support itself) be in the scope of this library?

In Go everything unknown is stored into an untyped field that the user can retrieve.

I made a quick and dirty implementation of the above approach in here which works for me, but this doesn't yet support truly arbitrary fields, only string fields. If there's interest in it here I can flesh this out.

reqwest 0.10 just switched to http 0.2 (unreleased as of yet, reqwest 0.10.0-alpha.2 still uses http 0.1).

I saw that a lot of feature refactoring just happened in this project to support all combinations of futures 0.1 / 0.3 and reqwest 0.9 / 0.10. I don't know what's the best option to handle the version of the http crate though. I see several options:

• The version of http could either be bound to the selected reqwest version (0.2 for reqwest 0.10 and 0.1 for reqwest 0.9), or
• There could be another feature flag pair http_0_1 and http_0_2, or
• This crate just switches to http 0.2 altogether

I feel that the last option might be the best. It would require some http 0.1 <-> http 0.2 type translation code in case reqwest 0.9 is used.

Anyway, I just wanted to open this issue to point out this upcoming incompatibility.

I encountered this when trying to implement an authentication flow against Twitch.

You can see that their documentation specifies the correct scope format (i.e. space-separated string), but in the example it responds with an array of strings. I've verified that this is also the case with the actual API.

I don't know if I'm doing something wrong, nor how proliferate these kind of implementations are. But from a pragmatic perspective it would be nice to be able to use oauth2-rs to get tokens from Twitch.

• Topic raised on their dev forum (but unfortunately ignored)
• Another one

Since async/await is about to be stabilized (7. Nov as far as I know) I think it would be great to have a branch until then that prepares the crate for that.

• Update dependencies:
  • futures = "0.1" to "0.3" (preview)
  • tokio-io preview
• Update to rust 2018 edition, remove some pre 2018 source code artifacts e.g. extern crates...
• Added toolchain file (prior to stabilization)

Not sure why the nightly CI is failing, it works locally using nightly-2019-10-20

When trying to build an actix-web based client for the http requiest, I get errors about missing Send markers. E.g. a stripped down example might be

async fn request()
{
    let mut response = awc::ClientBuilder::new()
	.finish()
	.get("")
	.send_body("")
	.await
	.unwrap();

    response.body().await.unwrap();
}

async fn request_async<FN, F>(f: FN) -> ()
where
    FN: FnOnce() -> F + Send,
    F:  std::future::Future<Output = ()> + Send,  /// <<<< removing this Send makes it work
{
    f().await
}

async fn auth()
{
    request_async(request).await;
}

fn main() {
}

which results into

error[E0277]: `std::rc::Rc<awc::ClientConfig>` cannot be sent between threads safely
   = help: within `impl std::future::Future`, the trait `std::marker::Send` is not implemented for `std::rc::Rc<awc::ClientConfig>`

(and much more).

The request_auth() function corresponds to oauth2:'s methods which have a similar signature.

When removing the Send requirement from F, things seem to be fine. In oauth2 this seems to be required due to #[async_trait] but accordingly its documentation this can be explicitly disabled by writing

#[async_trait(?Send)]

Is there a reason why Send is required for the http_client or would it be possible to avoid it (which makes writing awc clients much easier)?

rust-1.40.0 awc-1.0.1 actix-web-2.0 (futures-0.3) oauth2-3.0.0-alpha.7

hey Alex

here are a few things I'd like improve:

• [x] https://github.com/alexcrichton/oauth2-rs/pull/11 add tests

• [x] https://github.com/alexcrichton/oauth2-rs/pull/13 have all the exchange_ methods return Result<Token, TokenError>, change the TokenError#error field to an enum (it's a strict set according to the RFC), but add also an Other(String) value to the mix, where I'd map non-traditional errors and (json/form) parse errors

• [x] https://github.com/alexcrichton/oauth2-rs/pull/12 change the interface of Config a bit by adding builder-style field setters set_redirect_url(...) -> Config, set_response_type(...) -> Config, set_scopes(...) -> Config (or maybe add_scope(...) -> Config and work with one value at a time) so that setting up the whole OAuth2 flow would be as easy as:

  let mut config = Config.new("id", "secret", "http://auth", "http://token").set_redirect_url("http://redirect").set_response_type("authorization_code").set_scopes(...);
  let auth_url = config.authorize_url(...);
  

• [ ] ~~determine whether to parse token data or error data based on the HTTP status code (but I'd have to see if there's anything about this in the specs or if different implementations handle this properly)~~

• [ ] ~~the RFC says that scopes in the token response are separated by whitespace (not comma), so maybe implement something that handles both. I actually don't think this is so crucial but in some situations the user might authorize less scopes than the app actually requested. Google, for example, doesn't really allow that - you're either in or out.~~

• [x] https://github.com/alexcrichton/oauth2-rs/pull/14 https://github.com/alexcrichton/oauth2-rs/pull/15 add some real-life examples: let's say Google and Github

• [x] https://github.com/alexcrichton/oauth2-rs/pull/16 add some (basic) docs

it depends on how much free time I have so no promises, but in any case I'd like to hear your opinion first :)

I'm just starting to use this library to authenticate users using the "usual suspects" of providers (google, facebook, github etc...). To do so, I'm thinking I will need to initialize a collection of BasicClient types (a Client). The specifics for each would be hosted in a configuration file. An efficient way to do so would be to Deserialize the BasicClient values from the configuration.

What is the reason for not implementing the Serde traits for something like BasicClient?

Implemented #97

1. adding a Client::set_introspection_url method for setting the URL (which can be leveraged by multiple subsequent introspection calls, similar to the pattern for setting the auth_url xand token_url in Client::new, but without introducing a breaking change to that method) :heavy_check_mark:
2. adding a Client::introspect_token method that follows the same pattern as exchange_code, etc. (i.e., it should return an IntrospectionRequest struct). :heavy_check_mark:
3. defining a strongly-typed IntrospectionResponse struct leveraging the NewType pattern where appropriate :heavy_check_mark:
4. adding appropriate unit tests :heavy_check_mark:

Better to add features to turn on rustls in reqwest.

Library native-tls is dynamically linked and it's hard sometimes to set up the environment for it. I added features that enable rustls in reqwest but by default reqwest uses native-tls in feature default-tls and needs to be disabled to make work rustls.

So to use rustls with oauth2 all you need to specify:

oauth2 = { version = "3.0", features = ["reqwest-010", "reqwest-010-rustls"], default-features = false }

Hello

I got this parse error response when using let token_to_revoke = match Some(refresh_token) { Some(token) => token.into(), None => (&access_token).into(), }; client = client.set_revocation_uri( RevocationUrl::new(self.oauth2_endpoint.revocation_endpoint.clone()).unwrap(), ) client .revoke_token(token_to_revoke) .expect("This must have the right token") .request_async ...

I am not sure if I have some lacking steps in setting up sa client. Please let me know what I am missing.

Request: Request: URL=Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("graph.microsoft.com")), port: None, path: "/beta/me/invalidateAllRefreshTokens", query: None, fragment: None } Request: Header={"accept": "application/json", "content-type": "application/x-www-form-urlencoded"} Request: Method=POST Request: Body="token=M.R3_BL2.-CdSr1AhpVWufEK2FqWxHUAYved1A1yZu7o74VLPI9SxUVuf1pzn0roqgCOP6GLJaSULYpsVitIIwx6QeBxtOLOados1q7LxLrvdx6Z%21DnUyfrqeBSGdGvc4E4c6YfHOw8hVQHJYwpG240j74YLoi%21srUJWIqxDFwbVkCYC43rkFu4V2BwWg3MFdr7dGQYEaoNejGMIxsEQ2Nk%21T65wnxpoHfKyUNNqx4oTNssUhosJKn5F9dhQ5RkG2fHyezOZGycPfSnIO2zJwNAISFRQNgNlqQIspF2Z4ytnS6urTfy7I9yvRnGtSJPw%24%24&token_type_hint=refresh_token&client_id=CLIENT_ID"

Response: {"error":{"code":"InvalidAuthenticationToken","message":"Access token is empty.","innerError":{"date":"2022-11-24T07:25:58","request-id":"51403c6c-617a-4277-b1e1-06ba56269218","client-request-id":"51403c6c-617a-4277-b1e1-06ba56269218"}}}

It seems like secret types like PkceCodeVerifier are simply wrapping a string; is there a reason they don't implement Clone?

If I need to clone my verifier, is it fine to simply grab the secret from the existing one and use it to create a new one? Like so:

fn clone_verifier(verifier: &PkceCodeVerifier) -> PkceCodeVerifier {
    PkceCodeVerifier::new(verifier.secret().clone())
} 

Hello

I found a problem with DeviceAccessTokenRequest when using it as async. There is an async implementation found on your codes but there is a compile error when using it. I found a sample but it is a sync example https://docs.rs/oauth2/latest/oauth2/#device-code-flow. I am creating an async implementation of it.

pub async fn get_token(&mut self) -> Result<UserToken, Box<dyn std::error::Error>> 
{
    let request_token =
        self.client.as_ref().unwrap()
        .exchange_device_access_token(&self.devicecode_result.as_ref().unwrap());
        
    let token_result = request_token.request_async(async_http_client, std::thread::sleep, None).await?;

    println!("Access Token: {}", token_result.clone().access_token().secret().to_string());
    Ok(UserToken{token: token_result.clone().access_token().secret().to_string()})
}

Compile Errors: .request_async(async_http_client, std::thread::sleep, None).await?; | ^^^^^^^^^^^^^ () is not a future

2363 | SF: Future<Output = ()>, | ^^^^^^^^^^^^^^^^^^^ required by this bound in DeviceAccessTokenRequest::<'a, 'b, TR, TT, EF>::request_async

We are building an SPA in the frontend. Our design at this point involves navigating to the third party, and in the redirect, setting things up to then pass to the backend to obtain the access token.

The api of this library has raised some questions:

• Following the redirect, it's an arrival at a freshly loaded app, and the only way to check the code is to use some form of persistence as the frontend sees it (e.g. through local storage)
• Similarly for the Pkce challenge/verification
• The backend needs to receive from the frontend the pkce verifier.
• The BasicClient requires reconstruction in the backend

Alternatively, we could rejig our design such that it is all handled in the backend (i.e. the backend sends the authorisation url to the front end, but redirects to speak with the backend), and that might be the way we will end up going, but would rather do that because it's a choice in design, rather than a limitation of the api.

For context, the reason why we are doing the flow in the backend, rather than the frontend, is because when trying to authorize with github, it's blocked by CORS.

Fixes #179

This PR attempts to reduce unnecessary lifetimes. This is unfortunately at the expense of a little bit more complexity in handling the Futures. This effect could maybe be reduced somewhat with the use of the futures crate.

The other significant change here is the change from Arc<Fn() -> DateTime + 'b> to a type parameter which reduced the complexity of the future and I believe reduced the complexity of the lifetimes of DeviceAcessTokenRequest. However this is a breaking change!

When using request_async, the async function implicity captures self and therefore can lead to restricted lifetimes. For example

Given the following wrapper around BasicClient

pub struct Oauth2Client(oauth2::basic::BasicClient);

impl Oauth2Client {
    pub fn request_token(
        &self,
        code: AuthorizationCode,
        verifier: PkceCodeVerifier,
    ) -> impl Future<
        Output = Result<
            BasicTokenResponse,
            RequestTokenError<AsyncHttpClientError, BasicErrorResponse>,
        >,
    > {
        self.0
            .exchange_code(code)
            .set_pkce_verifier(verifier)
            .request_async(oauth2::reqwest::async_http_client)
    }
}

This won't compile with the following error:

error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds
  --> src/main.rs:17:9
   |
8  |           &self,
   |           ----- hidden type `impl Future<Output = Result<StandardTokenResponse<EmptyExtraTokenFields, BasicTokenType>, oauth2::RequestTokenError<oauth2::reqwest::Error<reqwest::error::Error>, StandardErrorResponse<BasicErrorResponseType>>>>` captures the anonymous lifetime defined here
...
17 | /         self.0
18 | |             .exchange_code(code)
19 | |             .set_pkce_verifier(verifier)
20 | |             .request_async(oauth2::reqwest::async_http_client)
   | |______________________________________________________________^
   |
help: to declare that the `impl Trait` captures `'_`, you can add an explicit `'_` lifetime bound
   |
16 |     > + '_ {

This is because CodeTokenRequest has a lifetime associated with Client and then subsequently gets captured in the future generated by request_async. We can modify request_async to return a non-capturing future instead.

pub fn request_async<C, F, RE>(
      self,
      http_client: C,
  ) -> impl Future<Output = Result<TR, RequestTokenError<RE, TE>>>
  where
      C: FnOnce(HttpRequest) -> F,
      F: Future<Output = Result<HttpResponse, RE>>,
      RE: Error + 'static,
  {
      futures::future::ready(self.prepare_request()).and_then(|http_request| {
          http_client(http_request).map(|res| {
              res.map_err(RequestTokenError::Request)
                  .and_then(endpoint_response)
          })
      })
  }

which will then not have the implicit lifetime and allow for the previous code to compile. I'm happy to implement this. I've used futures here which isn't a dependency, but I could create a custom Future as all request_async functions are basically the same with the exception DeviceAccessTokenRequest::request_async.