Django-oauth-toolkit: Grant type: All-in-one gives a "client is not authorized to use response_type token"

[wezzynl]

When setting-up an Application with the "All-in-one generic" authorization grant type, I cannot make an authorization request with response_type of 'token' (or 'code' for that matter...)

Maybe I'm doing something wrong but It looks like the function 'validate_response_type' in 'oauth2_provider.oauth2_validators.py' doesn't take GRANT_ALLINONE into account?

[masci]

Hi @wezzynl,
actually the GRANT_ALLINONE grant type should have been removed several commits ago - it was my bad, I was trying to wrap oauthlib api but I misunderstood its meaning.
But, since you are using it, what is your workflow, and what do you expect from using such type of grant type?

[wezzynl]

Hi Masci, thanks for the response. If I'm correct, right now, I should create two applications, one with the token flow and one with the authorization code flow. My thinking was to have one OAuth2 application that supports both the implicit token flow and the authorization code flow. (doing so by specifying the all-in-one grant type).

How would you go about setting up that one application supports both those flows?

[masci]

Hi @wezzynl sorry for the latency.
I double checked the all-in-one stuff but I think it's not feasable. We could provide a grant type with the meaning of "this Application works both with implicit token and authorization code" but I fear this would end in being another, brand new OAuth2 flow, which is definitely against the RFC.
I'm going to remove any reference to the GRANT_ALLINONE, thank you for having pointed out the issue.

[wezzynl]

Hi @masci Thank you for looking into it. I'm not seeing how this would be another OAuth2 flow. It's the same flow really.

Like on Facebook. You create 1 application and you can use the authorization code flow _and_ the implicit token flow. You don't need to create 2 applications: one that uses the authorization flow and the other application that uses the implicit token flow.

Either I'm missing something or the way it works now is that you'd need to create two applications when using Django Oauth Toolkit: one that uses the authorization flow and the other application that uses the implicit token flow. Somehow that feels odd but maybe that's just me :)

[masci]

Hi @wezzynl I dug into Facebook docs and the whole problem is now clearer to me. Actually such a workflow _is_ a new workflow (here I was right) but it's allowed by the standard (here I was completely wrong) and infact Facebook makes use of it. The token type used by Facebook to support both authorization code and implicit grant flows in one single app is code token and is documented here:

http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html#Combinations

So we could remove GRANT_ALLINONE and add something like GRANT_CODE_TOKEN but it's not trivial since it seems oauthlib does not support such grant type out of the box. Anyway I think supporting such feature would be favourable for the project so I'm going to make a branch and give it a try.

Thanks for the feedback, stay tuned!

[masci]

We need some code on the oauthlib side to support the "token code" respone type (a-la Facebook to be clear). Waiting for feedback from oauthlib.

[skrivanos]

@masci, I think you have misunderstood something in regards to this issue. What is asked for is not, in fact, a new workflow, it is simply the ability to use either of the already existing workflows (grant types) for the same application (client). The spec does not hinder this in any way as far as I know. The link you provided above is for supporting multiple response types simultaneously which is something else entirely.

I do not see a reason to not to allow using either the Authorization Code or Implicit grant types for the same application. However, the Password and Client Credentials grant types should have to be enabled explicitly as they are somewhat dangerous.

[yarbelk]

+1 for this - I have a use case where I have a resource (tied to an ApplicationModel) that needs to be editable by a secure sever and public clients, with different scopes. Permissions get really squirrly if I have to tie two Application instances with the two grant types to to the resource. Some users can use one flow, some use another.

[jarcoal]

It would be really nice to see this supported. I think that at some point most apps are going to need an Application that can support multiple flows.

Has anyone found a good work-around or is creating/maintaining 2+ applications the best way to go?

[jarussi]

Sorry for resurrecting a dead thread, but I also need this. Anyone found a solution / workaround for it?

[clintonb]

Any updates, @masci? What was the reason the all-in-one functionality was removed? Would you entertain reviewing/merging a restoration of similar functionality?

[clintonb]

@synasius @Girbons any interest in a PR restoring this functionality?

[jleclanche]

@clintonb If you can lay out a design doc + plan I can review that.

[clintonb]

@jleclanche no need. https://github.com/evonove/django-oauth-toolkit/pull/448 meets my needs, and should probably be suitable for others.

[jleclanche]

Cool, closing then.