Open cgreenhalgh opened 7 years ago
See also...
Google recommend that apps doing OAuth use custom URI scheme for the (secure/checked) callback URL on mobile, and http: to localhost on desktop. But not all Oauth services support custom URI schemes in the callback URL.
Copy/paste and programmatic extraction (e.g. from embedded frames) are also identified as deprecated options. These could/would be mediated via a simple application-specific global web site that just serves the callback URL and makes the returned token available to the user there.
perhaps I should stop talking to myself, but...
you can work around the issue of some oauth providers only supporting http/https callback URLs via a small dedicated web site that serves a user-client-specific response, i.e. custom scheme on iOS/Android, localhost URL on (local) desktop browser.
Is this related to RFC 6749 Implicit Grant Flow https://tools.ietf.org/html/rfc6749#section-4.2, eg., Fitbit https://dev.fitbit.com/build/reference/web-api/oauth2/#implicit-grant-flow?
Similarly, for Google, OAuth2 for Devices https://developers.google.com/identity/protocols/OAuth2ForDevices, though it only supports limited scopes.
The general issue of oauth (non)support in the app applies to any form of oauth use, because the missing bit is supporting the handoffs from the driver web page within the embedded app view to the system browser (for oauth) and back to the app/driver afterwards.
Where it is supported by the provider, using implicit grant and/or device-specific oauth avoids the problems of exposing long-lived/transferable oauth tokens to potentially untrusted databox drivers. But if they aren't supported by a particular provider then you have to choose your compromise solution (exposing user tokens or additional online service intermediaries).
Ok-- that being the case we might want to document it, perhaps pointing to Twitter driver as an exemplar (?). But I'm going to close this issue for now because open issues aren't a good way of documenting things, getting an unstated set of cloud service providers to support particular variants of OAuth doesn't seem likely, and the title of the issue isn't actually correct (it is possible, just not in a generic way and often not in a particular RFC-supported way)... If someone wants to pick this up and proposed something via the IETF etc to extend the spec to support the behaviour we need, by all means re-open it.
The first post in this thread lists the key features required for ANY oauth flow to work from within the app which are currently missing (i.e. app redirect -> system browser; browser redirect to app). Kev is working on these at the moment. So I'd suggest leaving this issues open until those are in. The stuff about provided-specific support is another (sub)issue.
Reopened and assigned to @ktg
@ktg I believe you have compleated this and updated the twitter driver as an example. If its working can you submit a PR. Did you document the process?
Noting for the record that oauth in this version of the twitter driver is supposed to work in browser and in app. But this currently depends on kevin's version of the core-ui.
To do oauth authorization from a driver UI viewed within the app :
AFAIK none of these work at the moment. ( @ktg ?!)