Django OAuth Toolkit "resource-owner password based" grant type

4
votes

I am trying to set up OAuth2 for Django + Rest Framework using Django OAuth Toolkit, and here's the puzzle I can't understand when using "Resource owner password-based" authorization type.

I can successfully get access_token for the same user that registered the Application (Client Owner) using:

enter image description here

However, when I try to use same client_id and client_secret, but change the username and password for a different user, I get

{ "error_description": "Invalid credentials given.", "error": "invalid_grant" }

So it seems like the registered application can only use one "resource owner" - the "application (client) owner" itself, which makes "resource owner password-based" authorization type useless, since it acts the same way as "client credentials" but without using "username" and "password". In other words, I need the registered application to act on behalf of another user, and not the user that has registered the application (me), but I can't get around it.

Of course I always can write custom authorization code, but shouldn't it be supported out of the box (I wonder)?

1
pythondjangooauth-2.0django-rest-framework
I'm having the same problem. The DOT docs are not helpful with application registering. – shenk
Did you find a solution ? I'm facing the same problem – Ahmed T. Ali
I've tested this and I face no problem: Meaning I can authenticate a user with their username and password without needing to add this user as the owner of the application. django-oauth-toolkit follows the rfc. Try to set a new app, from scratch, and do it again. If it doesn't work add more info – NBajanca
I am also facing the same issue, I am able to use resource owner password based with my old application but now the new application I am not able to use it, As it is the same django-oauth-toolkit version so I am think I am doing something wrong in the new application. – Chitrank Dixit
I'm facing the same issue, did you guys find a solution? – alfdev

1 Answers

0
votes

The issue was simple misconfiguration and misusage, which resulted in an ambiguous behaviour.

This works:

  • base64-encoded 'Authorization' header (client_id:client_secret)
  • Make sure the application settings set to 'resource owner password-based'. Note, that it can not be 'Public', client_secret is absolutely required for this flow.