[Feature Request]: Adding login via browser in the app

Gitstar-OC commented

2025-03-31 07:20:52 +00:00

(Migrated from github.com)

Preflight Checklist

I have searched the issue tracker for a feature request that matches the one I want to file, without success.
I use the latest version of YouTube Music (Application).

Problem Description

If I want to sign in, in the desktop app I need to do it through the app for which I need to create gmail inside of it, which takes up a very long time.

Proposed Solution

Most of the applications use what's called a browser login option where the login page opens in the default browser of user's choice and the signin happens there. If a signin is successful it redirects to the app with all the required details.

Alternatives Considered

N/A

Additional Information

No response

### Preflight Checklist - [x] I have searched the [issue tracker](https://github.com/th-ch/youtube-music/issues) for a feature request that matches the one I want to file, without success. - [x] I use the latest version of YouTube Music (Application). ### Problem Description If I want to sign in, in the desktop app I need to do it through the app for which I need to create gmail inside of it, which takes up a very long time. ### Proposed Solution Most of the applications use what's called a browser login option where the login page opens in the default browser of user's choice and the signin happens there. If a signin is successful it redirects to the app with all the required details. ### Alternatives Considered N/A ### Additional Information _No response_

👍 4

arjix commented

2025-03-31 08:53:08 +00:00

Owner

You see, there is an issue with this.
We did not make the "application"*, so we have no control over stuff like that.

What we have control of, is the computer itself, which means we could steal the cookies from your browser and use them to login.

That would make a lot of antiviruses unhappy and flag our app as a cookie stealer.

Not only that, using the same cookies on two different browsers means the cookie will be invalidated by google.

So even if we allowed the user to manually import the cookies, it'd still be an issue if they didn't delete the original cookies.

* by "application" I am referring to Google's cloud application id, which is required for an app to have google oauth

You see, there is an issue with this. We did not make the "application"*, so we have no control over stuff like that. What we have control of, is the computer itself, which means we could steal the cookies from your browser and use them to login. That would make a lot of antiviruses unhappy and flag our app as a cookie stealer. Not only that, using the same cookies on two different browsers means the cookie will be invalidated by google. So even if we allowed the user to manually import the cookies, it'd still be an issue if they didn't delete the original cookies. \* by "application" I am referring to Google's cloud application id, which is required for an app to have google oauth

👍 2

F3R96 commented

2025-03-31 14:42:31 +00:00

(Migrated from github.com)

Can I ask for another feature? I'm using Windows modded like macOS, and I would like to have the traffic light buttons like said OS instead of windows' one

Gitstar-OC commented

2025-04-02 14:44:59 +00:00

(Migrated from github.com)

I agree to what you said Arjix but still creating up a new email or login by entering the password with the email in the apps seems like a lengthy process to me and it takes a lot more time if you have turned up 3 factor verification! (I also use a yubikey). Also I might not enter my email password in an application.

jpambrun commented

2025-04-28 12:37:50 +00:00

(Migrated from github.com)

The oauth flow does not require stealing cookies. We should be able authorize this "device" to only access youtube.

I am very wary of putting my main google credentials in this or any untrusted application. Any contributor could add malicious code to steal all of your user's main google account. Even if you trusted every team members with your life (which I of course can't) there massive supply chain attack opportunity.

In my opinion, this is a critical issue, not merely a feature request.

Edit: I guess because this is only a wrapper around the website it can't be done otherwise, but yikes, makes it unusable.

The oauth flow does not require stealing cookies. We should be able authorize this "device" to only access youtube. I am very wary of putting my main google credentials in this or any untrusted application. Any contributor could add malicious code to steal all of your user's main google account. Even if you trusted every team members with your life (which I of course can't) there massive supply chain attack opportunity. In my opinion, this is a critical issue, not merely a feature request. Edit: I guess because this is only a wrapper around the website it can't be done otherwise, but yikes, makes it unusable.

👍 2

arjix commented

2025-04-28 13:06:42 +00:00

Owner

@jpambrun

The oauth flow does not require stealing cookies.

We did not make the "application"*, so we have no control over stuff like that.

--

Yes I saw ur edit, but I still got a notification about your message, so I am replying :)

@jpambrun > The oauth flow does not require stealing cookies. > We did not make the "application"*, so we have no control over stuff like that. -- Yes I saw ur edit, but I still got a notification about your message, so I am replying :)

JellyBrick commented

2025-05-10 14:20:36 +00:00

(Migrated from github.com)

The oauth flow does not require stealing cookies. We should be able authorize this "device" to only access youtube.

I am very wary of putting my main google credentials in this or any untrusted application. Any contributor could add malicious code to steal all of your user's main google account. Even if you trusted every team members with your life (which I of course can't) there massive supply chain attack opportunity.

In my opinion, this is a critical issue, not merely a feature request.

Edit: I guess because this is only a wrapper around the website it can't be done otherwise, but yikes, makes it unusable.

YTM (Web) is designed with the assumption that cookies are used, so OAuth is not available.
Another option is https://github.com/th-ch/youtube-music/issues/3165#issuecomment-2765571770

> The oauth flow does not require stealing cookies. We should be able authorize this "device" to only access youtube. > > I am very wary of putting my main google credentials in this or any untrusted application. Any contributor could add malicious code to steal all of your user's main google account. Even if you trusted every team members with your life (which I of course can't) there massive supply chain attack opportunity. > > In my opinion, this is a critical issue, not merely a feature request. > > Edit: I guess because this is only a wrapper around the website it can't be done otherwise, but yikes, makes it unusable. YTM (Web) is designed with the assumption that cookies are used, so OAuth is not available. Another option is https://github.com/th-ch/youtube-music/issues/3165#issuecomment-2765571770

qb20nh commented

2025-05-20 00:48:38 +00:00

(Migrated from github.com)

How do I know the login page presented in the application is not an impersonation?

👍 1

arjix commented

2025-05-20 05:07:55 +00:00

Owner

You can open the devtools, and execute the JavaScript window.location.href to see the current url of the page

But honestly that means shit, because we have full control of the page.

You could review the source code, and build from source, that's the only viable way.

But even then, how good are you at reviewing code you did not write?

You can open the devtools, and execute the JavaScript `window.location.href` to see the current url of the page But honestly that means shit, because we have full control of the page. You could review the source code, and build from source, that's the only viable way. But even then, how good are you at reviewing code you did not write?

qb20nh commented

2025-05-20 11:10:10 +00:00

(Migrated from github.com)

Of course, logging in even with external page would mean trusting the app over your google account. Supporting passkeys would be also a good solution. Enter the username and then the system dialogue pops up for authentication. If the site is not legit there would not be any passkeys listed.

Upstream issue: https://github.com/electron/electron/issues/24573

Edit: Hmm, even if electron supported passkeys fully, passkeys on macOS apparently needs app signing, which is probably not viable for this project unless someone donates their apple developer account.

Of course, logging in even with external page would mean trusting the app over your google account. Supporting passkeys would be also a good solution. Enter the username and then the system dialogue pops up for authentication. If the site is not legit there would not be any passkeys listed. Upstream issue: https://github.com/electron/electron/issues/24573 Edit: Hmm, even if electron supported passkeys fully, passkeys on macOS apparently needs app signing, which is probably not viable for this project unless someone donates their apple developer account.

joaomoreno commented

2025-09-09 07:20:28 +00:00

(Migrated from github.com)

This is the reason why I don't use this app.

JellyBrick commented

2025-09-09 13:22:35 +00:00

(Migrated from github.com)

This is the reason why I don't use this app.

@joaomoreno So, do you have any solutions for this issue?
ref: https://github.com/th-ch/youtube-music/issues/3165#issuecomment-2868905346

> This is the reason why I don't use this app. @joaomoreno So, do you have any solutions for this issue? ref: https://github.com/th-ch/youtube-music/issues/3165#issuecomment-2868905346

Rows
Columns

[Feature Request]: Adding login via browser in the app #3165

Preflight Checklist

Problem Description

Proposed Solution

Alternatives Considered

Additional Information