Puzzled by native use cases

[montdidier]

When attempting to use the authentication_code flow with a native iOS application there seems to be a use case mismatch with the way doorkeeper is designed.

As far as I can tell with doorkeeper one should

• set the redirect_uri in the native app
• setup doorkeeper to recognise this url (application redirect_url)
• set the native_redirect_uri to match in the doorkeeper initialiser

In an iOS application it seems almost expected (there may be other use cases I am not aware of) that one would use a registered custom scheme.

However doorkeeper does not redirect upon successful authentication to the expected custom scheme URI but instead redirects to the hardcoded URI of the style:

https://server.domain.tld/oauth/authorize/native?code=[CODE]

Which then presents the CODE in a view. This behaviour seems similar as what one would expect using the urn:ietf:wg:oauth:2.0:oob URI as per Google's documentation. The OOB request_uri hint never became a standard but Google still uses it.

As far as I understand it this approach has been superseded by the approach(es) documented in rfc8252. Doorkeeper as it currently is, doesn't seem to support any of these.

Short story. I would expect doorkeeper to return a redirect to the native app's custom scheme.

e.g. appname://oauth/callback?code=[CODE] or similar.

[nbulaj]

Hi @montdidier . I think we can close this issue, right?

[montdidier]

@nbulaj Yes, we should close it.

[montdidier]

Addressed in referenced issues and PRs