CODEWITHSUNDEEP
djangooauth-2.0
beddamadre
beddamadre

Reputation: 1603

django oauth2 rest authentication flow for mobile apps

I'm trying to figure out which is the best flow to interact from my mobile app to my api.

I'm using those packages:

https://github.com/evonove/django-oauth-toolkit
http://www.django-rest-framework.org

I would like to have this flow:

  1. The user compile the registration view on my mobile app with user & password
  2. The user submit the registration
  3. My app make a request to my backend to obtain a token for the app
  4. App with the token make a call to the user registration api
  5. My backend register the user, login it and return a user token for future calls.

Is my flow correct?
If I use Resource owner password-based and I make request like this:

 curl -X POST -d "grant_type=password&username=username&password=password" -u "client_id:client_secret" http://127.0.0.1:8000/api/v2/oauth/token/

I get:

 {"access_token": "09Vf0HD5nCPSEvLAnjxrghZPHfvE4c", "token_type": "Bearer", "expires_in": 36000, "refresh_token":"yDmovryDlGhkLVV6T2rTgFQxnNtguq", "scope": "read write groups"}

But If I'm tring to get an access token for my app with this:

 curl -X POST -d "grant_type=client_credentials" -u "client_id:client_secret" http://127.0.0.1:8000/api/v2/oauth/token/

I get:

 {"error": "unauthorized_client"}

So my doubt is:
How should I setup my application?
Which Authorization grant type my oAuth2 application should have?

enter image description here

Upvotes: 3

Views: 2563

Answers (1)

synasius
synasius

Reputation: 323

resource owner password credential authenticates your application on behalf of a user (the resource owner) thus grants access to data related to that user.

client_credential grant type is needed when you want to authenticate your application and not the user. The issued access token won't be bound to an user but to an application and this tokens usually only allow access to application related data.

If you want to enable this grant in DOT you should choose "Client Credential" in the application creation form.

The flow you described looks ok, but keep in mind that you need two applications: one for the client credentials grant and one for the password grant.

On the server side, the registration endpoints should have a permission check that allow requests only from client_credential access_tokens. When the registration succeed (say 201) you can obtain a "user token" using username and password before deleting them.

Just one question, I don't get why you need python social auth. There is no mention about it in the flow you described.

Upvotes: 2

Related Questions