Allow "urn:ietf:wg:oauth:2.0:oob:auto" as a redirect_uri in the Aplication admin

[manelclos]

Hi, the Application model admin is not currently allowing to set redirect_uris to urn:ietf:wg:oauth:2.0:oob:auto.

The Application model clean method does not take it into account, currently only allowing http and https schemes.

It would be great if this could be improved. Would a patch be accepted? or is this due to a design decision?

Also, trying to access the authorize url fails by default, we had to manually add the crsf_exempt decorator, as the AuthorizationView class is not decorated with csrf_exemp as the TokenView and TokenRevokeView are. Not a problem, but unexpected in the JSON use case.

[vector-kerr]

+1 to this request - if my understanding is correct, this would allow for native app URIs with registered custom schemes.

[manelclos]

Hi @vector-kerr, we are using this to get an authorization code from the authorize endpoint from a SPA, this is, no navigation to the authorize endpoint, no user confirmation.

[PoDuck]

Is this not already implemented in the setting ALLOWED_REDIRECT_URI_SCHEMES as documented here?

[arineto]

Any updates on this? I haven't been able to set the ALLOWED_REDIRECT_URI_SCHEMES to allow native URLs like com.oauthapp:// for example.

SOLVED: I was able to make it using the URI like com.oauthapp://redirect and setting the ALLOWED_REDIRECT_URI_SCHEMES to ["http", "https", "com.oauthapp"]

[dmvol81]

Hi, the Application model admin is not currently allowing to set redirect_uris to urn:ietf:wg:oauth:2.0:oob:auto.

The Application model clean method does not take it into account, currently only allowing http and https schemes.

It would be great if this could be improved. Would a patch be accepted? or is this due to a design decision?

Also, trying to access the authorize url fails by default, we had to manually add the crsf_exempt decorator, as the AuthorizationView class is not decorated with csrf_exemp as the TokenView and TokenRevokeView are. Not a problem, but unexpected in the JSON use case.

I knew nothing of what's going on. This is pure BS.

[n2ygk]

I knew nothing of what's going on. This is pure BS.

Not sure what you mean by this. This appears to have been solved at https://github.com/jazzband/django-oauth-toolkit/issues/971#issuecomment-948779327

But see also https://github.com/jazzband/django-oauth-toolkit/pull/774#issuecomment-592991489 where this is a deprecated feature.

Feel free to reopen if not.

[danlamanna]

Not the original issue creator, but I think this is a legitimate bug.

urn:ietf:wg:oauth:2.0:oob and urn:ietf:wg:oauth:2.0:oob:auto are treated as valid by certain parts of DOT, particularly the auth view. However, if a user attempts to set an application redirect URI as one of them, it's considered invalid (because it has no scheme): (This occurs in the admin as well).

Forcibly setting this as the redirect URI by directly mutating the model allows everything to flow as usual.

As an aside on out of band OAuth flows: I know DOT has marked oob as deprecated, to be replaced by RFC8252 - however that RFC is really targeted at Android/iOS and other "native" applications (cc @andersk from #774). A command line tool for example doesn't have any real method for handling a custom redirect URI. The only alternative would be to spin up a localhost server, which can often be a problem in scenarios where users aren't allowed to bind ports.

[n2ygk]

@danlamanna

I know DOT has marked oob as deprecated, to be replaced by RFC8252 - however that RFC is really targeted at Android/iOS and other "native" applications (cc @andersk from #774). A command line tool for example doesn't have any real method for handling a custom redirect URI. The only alternative would be to spin up a localhost server, which can often be a problem in scenarios where users aren't allowed to bind ports.

Do you have examples of specific use cases where the CLI client is not able to open a listener on the loopback address or use other approach examples given in RFC8252 Appendix B for Windows, MacOS and Linux?

I am still loath to increase support of insecure features that are not in the OAuth2 BCP.

See also this IETF OAUTH-WG thread.

[n2ygk]

Hearing no further. The decision to remove oob support in the next major release stands.

[Gophish001]

ok