OAuth 2.0 - custom callback scheme

[Davy De Waele]

Hi,

I'm planning to migrate an Android app using OAuth 1.0a to Oauth 2.0.

In OAuth 1.0a, in order to intercept the token, I used a callback URI with a custom scheme (xoauth://callback) so that my Android app could easily intercept it.

It appears this is no longer possible with OAuth 2.0 as I'm getting an invalid scheme error when specifying the above callback URI.

Any idea on how I should proceed ? I simply want to do a local callback in the app to intercept the token from the callback URI. 

Regards,

Davy

[Davy De Waele]

Managed to get around it by using a localhost callback and intercepting it in a Webview.

I did a writeup, so if Android developers are interested : http://blog.doityourselfandroid.com/2011/08/06/oauth-2-0-flow-android/

[Marius Scurtescu]

Hi Davy,

Out of curiosity, why do you prefer the localhost redirect URI as
opposed to OOB? In both cases you need an embedded view

Thanks,
Marius

[Davy De Waele]

I guess it feels more natural, simpler and cleaner to intercept a callback URL and fetch a request parameter. 

I'm also not sure that in Android / iOS it's that easy to retrieve the title of the embedded view. That would mean we would need to resort to polling the embedded view content, retrieving the HTML, parsing the HTML title tag, ....... seems like a lot of messy code to me :)

Obviously, having the user do copy-pasting is also not an option (don't understand why that option is even mentioned). I wonder if people actually doing implementation like that ?

When I started with Oauth (1.0), I went on to understand the internals (from OAuth 1.0 to 2.0). I think it's interesting to know what happens on the hood.

However, as a developer, I don't want to be bothered with these internals in my code. I want a higher abstraction of the entire OAuth spec.

The Google APIs Client Library for Java provides me that abstraction, and intercepting a callback URL to fetch a request param is something I'm willing to do. Anything beyond that is to messy for me :)

Don't know if it's the good approach, but it works for me. I had high hopes for the Android AccountManager integration with OAuth 2.0, as that looked like a good (browserless) solution, but I don't think it's production ready yet. . 

[Marius Scurtescu]

Hi,

See comments below...

On Mon, Aug 8, 2011 at 3:10 PM, Davy De Waele <ddew...@gmail.com> wrote:
> I guess it feels more natural, simpler and cleaner to intercept a callback
> URL and fetch a request parameter.
> I'm also not sure that in Android / iOS it's that easy to retrieve the title
> of the embedded view. That would mean we would need to resort to polling the
> embedded view content, retrieving the HTML, parsing the HTML title tag,
> ....... seems like a lot of messy code to me :)

I see. Would a specific query parameter on the OOB page URL help?

> Obviously, having the user do copy-pasting is also not an option (don't
> understand why that option is even mentioned). I wonder if people actually
> doing implementation like that ?

Copy-paste is the absolute simplest implementation. It can help in
developer mode, if nothing else. There are very simple command line
clients that print out a URL, you follow them in a browser and at the
end you copy-paste the authorization code back to the tool.

> When I started with Oauth (1.0), I went on to understand the internals (from
> OAuth 1.0 to 2.0). I think it's interesting to know what happens on the
> hood.
> However, as a developer, I don't want to be bothered with these internals in
> my code. I want a higher abstraction of the entire OAuth spec.
>
> The Google APIs Client Library for Java provides me that abstraction, and
> intercepting a callback URL to fetch a request param is something I'm
> willing to do. Anything beyond that is to messy for me :)

Yes, makes sense. I see your point.

> Don't know if it's the good approach, but it works for me. I had high hopes
> for the Android AccountManager integration with OAuth 2.0, as that looked
> like a good (browserless) solution, but I don't think it's production ready
> yet. .

True, if it was ready then the account manager would be the best option.

Marius

[Davy De Waele]

On Tuesday, August 9, 2011 12:30:52 AM UTC+2, Marius Scurtescu wrote:

Hi,

See comments below...

>I see. Would a specific query parameter on the OOB page URL help?

As the user always needs to authorize the request through a browser, there's not much difference between the native flow and the web flow

native flow : redirect to https://accounts.google.com/o/oauth2/approval?xsrfsign=AC9jObYAAAAATkBthso8KYSjtDAf0IxOwA8YqjzD0Nss&some_new_query_param=XXX.

web flow : redirect to http://localhost?code=XXX

I would still prefer the web flow in a mobile application as I have far more control over the redirection. 

But one can ask why a distinction is made ? You need the same technical capabilities for both native flow and web flow (being able to intercept the redirect).

I guess the only real use-case for the native flow is for command line stuff, pure desktop apps, and platform integrators (like the Android core team could build something based on OOB,do all the OOB handling internally, and pass on a token to the client app).

But despite what the docs say (http://code.google.com/apis/accounts/docs/OAuth2.html#IA) I don't think regular developers on mobile platforms will be using the native flow.

 

[Marius Scurtescu]

Hi,

In both cases technically the flow is the same. With OOB the redirect
URI is different/special, that's the only difference.

Also, in both cases when you register the client you have to register
it as a native app. Native apps are allowed to use any localhost
redirect URI. Ideally the client can use an embedded web server in
which case there is no need for embedded web view. So, localhost is
definitely one of the main options for native apps.

On Windows for example it is very difficult to deal with localhost
URLs, firewalls and security policies will prevent a redirect to such
URLs.

Marius

[Davy De Waele]

I see your point.

When I referred to native flow before, I was referring to the urn:ietf:wg:oauth:2.0:oob redirection uri usage only, not so much the concept of a "native client".

Is there any difference between registering a native client and a web based client. (each support a redirection URI to localhost, so no difference there).

Does Google do any special handling based on the client type (besides urn:ietf:wg:oauth:2.0:oob usage) ?

A lot of cmd line examples start an embedded server, and point the callback to the server using a landing page to do the cleanup.

I don't know if it would be advisable in an Android app to start an embedded server, and it wouldn't work on iOS.

But in general, registering a native client, using a localhost callback on an Android/iOS platform is perfectly OK if I understand correctly ?

 

[Marius Scurtescu]

Comments below...

On Mon, Aug 8, 2011 at 4:20 PM, Davy De Waele <ddew...@gmail.com> wrote:
> I see your point.
> When I referred to native flow before, I was referring to the
> urn:ietf:wg:oauth:2.0:oob redirection uri usage only, not so much the
> concept of a "native client".
> Is there any difference between registering a native client and a web based
> client. (each support a redirection URI to localhost, so no difference
> there).
> Does Google do any special handling based on the client type
> (besides urn:ietf:wg:oauth:2.0:oob usage) ?

Google limits what features and flows are available to a native
client. You can do only the web server flow for now, and
auto-approvals will never be enabled. On the other hand, a native
client does not have to explicitly register any redirect URIs.OOB and
localhost just work.

The wording on the consent page is also different for web and native apps.

> A lot of cmd line examples start an embedded server, and point the callback
> to the server using a landing page to do the cleanup.
> I don't know if it would be advisable in an Android app to start an embedded
> server, and it wouldn't work on iOS.

Right, the embedded web server would work only on desktop, and will
probably not work on Windows.

> But in general, registering a native client, using a localhost callback on
> an Android/iOS platform is perfectly OK if I understand correctly ?

Not sure. You are relying on the fact that some "unable to connect"
message is shown and that query parameters are preserved. Is this
guaranteed to be the case? What if the web view code in the OS or some
system policy breaks that?

Marius

[Davy De Waele]

Good point. You might have very well convinced me to tryout OOB :)

Gonna give it a try tomorrow as its almost 2am here .... Not a good time to try something new (unless it involves alcohol) :)

Thanks a lot for the new insights !

[Chris Johnson]

On Monday, August 8, 2011 7:39:39 PM UTC-4, Marius Scurtescu wrote:

Not sure. You are relying on the fact that some "unable to connect"
message is shown and that query parameters are preserved. Is this
guaranteed to be the case? What if the web view code in the OS or some
system policy breaks that?

On iOS, you can examine the URL that's about to be loaded by a web view and decide whether you want the web view to load it or whether you'd rather handle it some other way. So if I saw that the URL that was about to be loaded contained the string '://localhost', I'd close the web view, pluck the authorization code from the URL, and then use it to get the OAuth tokens. 'localhost' could just as well be 'mistermxyplyzylk' or any other string, or even a valid URL on my own domain; I just need to have a reliable way of knowing that the URL that's about to be loaded is the redirect_uri, which I know contains the authorization code (or error). This URL will never actually be accessed.

So the web flow, rather than the native/OOB flow, seems to be the way I'd go about it in an iOS app. Is there anything wrong with doing this, from Google's point of view?