[GH-ISSUE #487] Support for alternate OAuth clients #363

New issue

Closed

opened 2026-02-27 23:00:23 +03:00 by kerem · 1 comment

kerem commented

2026-02-27 23:00:23 +03:00

Owner

Originally created by @jcbirdwell on GitHub (Dec 17, 2023).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/487

Originally assigned to: @jcbirdwell on GitHub.

Is your feature request related to a problem? Please describe.
There didn't seem to be a way to clearly and easily change the underlying OAuth client being used to retrieve user credentials. This acted as a barrier to any added level of control, scalability, and end-user clarity that comes with using a custom OAuth client.

Describe the solution you'd like
An implementation of YTMusicOAuth that allows for a client id and secret to be provided as parameters, which will be used instead of those found in constants for user login and header creation, and subsequent integration into the YTMusic class.

Describe alternatives you've considered
1a. Simply changing the constants: While this solution is certainly the easiest path to the end goal, it's implementation lacks clarity, stability, and flexibility all of which would make it more of a pain than just writing in the feature.
1b. Ability to change the client id and secret via environmental variables. This was what I went with for the first iteration of the proposed changes, but it ended up not being all that much better in terms of clarity and flexibility in practice.
2. Subclassing of YTMusicOAuth and the ability to provide YTMusic with the OAuth instance directly: While this is probably the top of the line solution, its also the heaviest. The proposed version accomplishes about the same end result, while maintaining the same general structure and flow as the current code and the efficiency boost and simplicity of session sharing at a smaller scale. It also avoids any code duplication which could result from maintaining compatibility with browser based authentication.
3. Just not doing it: It's a niche issue that adds potentially unwarranted complexity, but I felt the added level of control and utility significantly outweighed this small increase to complexity. Additionally, the changes posture the package in such a way as to be more easily forked/upgraded into a wrapper for the official API, whenever that arrives.

Additional context
It was a feature that I wanted for my use-case and therefore something I was going to write anyway. I figured I'd offer it as a contribution instead of just hoarding it.

Originally created by @jcbirdwell on GitHub (Dec 17, 2023). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/487 Originally assigned to: @jcbirdwell on GitHub. **Is your feature request related to a problem? Please describe.** There didn't seem to be a way to clearly and easily change the underlying OAuth client being used to retrieve user credentials. This acted as a barrier to any added level of control, scalability, and end-user clarity that comes with using a custom OAuth client. **Describe the solution you'd like** An implementation of YTMusicOAuth that allows for a client id and secret to be provided as parameters, which will be used instead of those found in constants for user login and header creation, and subsequent integration into the YTMusic class. **Describe alternatives you've considered** 1a. Simply changing the constants: While this solution is certainly the easiest path to the end goal, it's implementation lacks clarity, stability, and flexibility all of which would make it more of a pain than just writing in the feature. 1b. Ability to change the client id and secret via environmental variables. This was what I went with for the first iteration of the proposed changes, but it ended up not being all that much better in terms of clarity and flexibility in practice. 2. Subclassing of YTMusicOAuth and the ability to provide YTMusic with the OAuth instance directly: While this is probably the top of the line solution, its also the heaviest. The proposed version accomplishes about the same end result, while maintaining the same general structure and flow as the current code and the efficiency boost and simplicity of session sharing at a smaller scale. It also avoids any code duplication which could result from maintaining compatibility with browser based authentication. 3. Just not doing it: It's a niche issue that adds potentially unwarranted complexity, but I felt the added level of control and utility significantly outweighed this small increase to complexity. Additionally, the changes posture the package in such a way as to be more easily forked/upgraded into a wrapper for the official API, whenever that arrives. **Additional context** It was a feature that I wanted for my use-case and therefore something I was going to write anyway. I figured I'd offer it as a contribution instead of just hoarding it.

kerem

2026-02-27 23:00:23 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 23:00:24 +03:00

Author

Owner

@sigma67 commented on GitHub (Dec 17, 2023):

Hi, I'm in favor of your contribution, although I think we can simplify some things. Continued in #488.

@sigma67 commented on GitHub (Dec 17, 2023): Hi, I'm in favor of your contribution, although I think we can simplify some things. Continued in #488.