Inconsistency with handling client credentials passed in request about django-rest-framework-social-oauth2

[PhilipGarnero]

I don't understand you here. Why would you want to pass client id and secret to those views ?

[ashishtajane]

I am new to oAuth in general, so please bear with me if this sounds a newbie question.
So, what is the use of client id and secret in general in these requests ?
My understanding was, we can identify and verify different clients with these -- like mobile app, webapp, desktop app are different clients, also we can provide API access to third parties for various purposes so each third party becomes a client.
So, here, we can verify a normal login request (/auth/token/) is coming from genuine client as client credentials are a must for this view. But for social logins, someone can get an access_token using /auth/convert-token/ view even if they don't have client credentials. And if we are allowing this, then what is the use of using client id and secret in those other views at all?

[PhilipGarnero]

Hum... No, you're right this is a legitimate question.
For now, we are using the Owner application by default when converting a token. This means that every token you generate with this will belong to our app. This is fine when you don't handle third party clients but when you'll need them, you will be stuck with a good part of tokens not actually belonging to them and as a result probably breaking some oauth2 features.
Making this changes will break the api but it seems necessary.
Thank you for this report I will update the code and release a new version as soon as I'm free.

[ashishtajane]

Cool, Thanks! 👍
Do let me know if I could be of any help, as I am using this currently in my app.

[PhilipGarnero]

After some thinking, this is more complicated than I first thought.
Depending on the client type of the application, the parameters needed don't limit themselves to client_id and secret.
I probably need to implement the exact same behavior as /token but I will need to investigate on how I could handle the different grants and clients using it.

[PhilipGarnero]

I think the OauthlibMixin provided by oauth2_provider should do it with some customizations.
I'll try this tomorrow

[felix-d]

So how does it go? If you need some help I could try to give a hand. This module is crucial for me :P Well i don't have the need for third party clients right now but that might become a possibility in the future. When the issue is resolved, I'll link the repo to my blog post as well. It naively discusses the usage of python social auth with oauth2 toolkit but your module is way more complete and right than what I wrote lol

[PhilipGarnero]

Well, I think this is fixed now.
Please tell me if that fulfills your needs and report any bug encountered.
I'll close this for now.