Add the possibility to create oauth token from another source (not from a TV or small device)

[saurL]

Hello @nick42d,

First of all, thank you for this repo — great work!

I'm currently working on an app that interacts with YouTube Music. From what I understand, the only way to obtain an OAuth token at the moment is through the "TV device flow", which requires the user to enter a code displayed on the device into their phone or computer. This isn’t ideal in cases where the "device" is actually a server.

I’ve been using the standard OAuth2 flow to authenticate with Google (with the crate oauth2), but I'm now facing a limitation: I can't instantiate an OAuthToken directly because its fields are private.

Implementing the full OAuth flow with PKCE is doable — it requires handling and storing the PKCE challenge, but it’s manageable.

I think a good first step would be to introduce a from_standard_token_response method (or similar), which would allow developers to construct an OAuthToken from a standard token response — regardless of how the token was obtained.

I will definitely implement it in a fork of this repo and if it is welcome It would be a pleasure to contribute to this project

[nick42d]

G'day @saurL , thanks for the kind words!

Definitely keen to support alternative oauth flows within ytmapi_rs.

I've allowed for some user extensibility in the design (since YtMusic is generic across AuthToken), so I have a couple of questions for you to figure out if this should be a new AuthToken type or methods on the existing OAuthToken:

• Is the token you are going to generate usable for all query types? The TV one I use doesn't support uploads, and this is enforced at compile time on the Query trait. Therefore, if your token supports different query types, this should be a new AuthToken type instead of extensions to OAuthToken
• Does the token you generate produce the same output json and errors as the TV device token? I have provisioned for this to be potentially different depending on the token via the intermediate deserialize_response method on AuthToken.
• Keen to know some more details about how you are generating the tokens with PKCE as this could be a neat feature in ytmapi_rs as well.

In the mean time, I have commenced PR #262 to allow user to supply any AuthToken - this would mean you could write your own custom AuthToken if you wished (although, happy to have custom AuthTokens merged to ytmapi_rs if it makes sense too).

Furthermore, if you have any questions or feedback on the design and usage of ytmapi_rs, please don't hesitate to ask.

Cheers Nick

[saurL]

I have no idea yet if this token supports uploading, and the same goes for error handling. Why would the error change depending on your token type?

I took a look at your PR. The idea is a bit different. My approach was basically to make a public constructor for OAuthToken.

I didn’t implement a new function directly, but rather a function that converts a token from the oauth2 crate into an OAuthToken. I actually realized that creating a public new function would have been easier in my use case, because I need to store the token data in a database after getting the access token.

Regarding the generation of the OAuth token using PKCE, here is the oauth2 documentation:

let client = BasicClient::new(ClientId::new("client_id".to_string()))
    .set_client_secret(ClientSecret::new("client_secret".to_string()))
    .set_auth_uri(AuthUrl::new("http://authorize".to_string())?)
    .set_token_uri(TokenUrl::new("http://token".to_string())?)
    // Set the URL the user will be redirected to after the authorization process.
    .set_redirect_uri(RedirectUrl::new("http://redirect".to_string())?);

// Generate a PKCE challenge.
let (pkce_challenge, pkce_verifier) = PkceCodeChallenge::new_random_sha256();

// Generate the full authorization URL.
let (auth_url, csrf_token) = client
    .authorize_url(CsrfToken::new_random)
    // Set the desired scopes.
    .add_scope(Scope::new("read".to_string()))
    .add_scope(Scope::new("write".to_string()))
    // Set the PKCE code challenge.
    .set_pkce_challenge(pkce_challenge)
    .url();

We then need to send the URL to the user. After completing the auth flow, the user sends the authorization code to the server, which can then request the access token and refresh token like this (which requires storing the pkce_verifier):

let http_client = reqwest::ClientBuilder::new()
    // Following redirects opens the client up to SSRF vulnerabilities.
    .redirect(reqwest::redirect::Policy::none())
    .build()
    .expect("Client should build");

// Now you can trade it for an access token.
let token_result = client
    .exchange_code(AuthorizationCode::new("some authorization code".to_string()))
    // Set the PKCE code verifier.
    .set_pkce_verifier(pkce_verifier)
    .request_async(&http_client)
    .await?;

With some documentation, this could become a feature of the crate — but is it really necessary?
I honestly feel like just making a public constructor for OAuthToken would solve my issue, and maybe yours too.

Actually, what’s the point of writing our own custom AuthToken? Doing so allows users to personalize how the token behaves — but is that necessary?
In what cases would the user want the token to behave differently?

Best regards,
Lucas

[nick42d]

I have no idea yet if this token supports uploading, and the same goes for error handling. Why would the error change depending on your token type?

I'm unsure with OAuth2, however it's an allowance in the design to produce better error messages when user has provided an invalid or expired token (particularly BrowserToken).

I took a look at your PR. The idea is a bit different. My approach was basically to make a public constructor for OAuthToken.

I didn’t implement a new function directly, but rather a function that converts a token from the oauth2 crate into an OAuthToken. I actually realized that creating a public new function would have been easier in my use case, because I need to store the token data in a database after getting the access token.

Regarding the generation of the OAuth token using PKCE, here is the oauth2 documentation:

let client = BasicClient::new(ClientId::new("client_id".to_string()))
    .set_client_secret(ClientSecret::new("client_secret".to_string()))
    .set_auth_uri(AuthUrl::new("http://authorize".to_string())?)
    .set_token_uri(TokenUrl::new("http://token".to_string())?)
    // Set the URL the user will be redirected to after the authorization process.
    .set_redirect_uri(RedirectUrl::new("http://redirect".to_string())?);

// Generate a PKCE challenge.
let (pkce_challenge, pkce_verifier) = PkceCodeChallenge::new_random_sha256();

// Generate the full authorization URL.
let (auth_url, csrf_token) = client
    .authorize_url(CsrfToken::new_random)
    // Set the desired scopes.
    .add_scope(Scope::new("read".to_string()))
    .add_scope(Scope::new("write".to_string()))
    // Set the PKCE code challenge.
    .set_pkce_challenge(pkce_challenge)
    .url();

We then need to send the URL to the user. After completing the auth flow, the user sends the authorization code to the server, which can then request the access token and refresh token like this (which requires storing the pkce_verifier):

let http_client = reqwest::ClientBuilder::new()
    // Following redirects opens the client up to SSRF vulnerabilities.
    .redirect(reqwest::redirect::Policy::none())
    .build()
    .expect("Client should build");

// Now you can trade it for an access token.
let token_result = client
    .exchange_code(AuthorizationCode::new("some authorization code".to_string()))
    // Set the PKCE code verifier.
    .set_pkce_verifier(pkce_verifier)
    .request_async(&http_client)
    .await?;

With some documentation, this could become a feature of the crate — but is it really necessary? I honestly feel like just making a public constructor for OAuthToken would solve my issue, and maybe yours too.

Thanks for the information! Perhaps you are right, in future I will have a play around with integrating this and see how it feels to use.

Actually, what’s the point of writing our own custom AuthToken? Doing so allows users to personalize how the token behaves — but is that necessary? In what cases would the user want the token to behave differently?

The primary reason for this feature is to allow users to resolve Google breaking changes themselves, without having to wait on upstream. This would allow app developers to more quickly hotfix for example. However a side benefit is that users with requests similar to yours can now develop their own tokens if they desire.

Best regards, Lucas

Happy to go ahead with the new constructor for now, since we aren't sure on the allowed queries and error handling.