Fwd: Interesting critique of OAuth by one of its creators

[Melvin Carvalho]

FYI

---------- Forwarded message ----------
From: Noah Mendelsohn <n...@arcanedomain.com>
Date: 22 March 2013 16:31
Subject: Interesting critique of OAuth by one of its creators
To: "www...@w3.org" <www...@w3.org>


Eran Hammer has published a detailed critique of OAuth at [1]. Well worth reading for anyone interested in Web authentication. His conclusion:

"If you're looking to implement authorization for your website, I recommend to sticking with well understood secure designs, such as HTTP Basic Authentication over SSL/TLS (or HTTP Digest Authentication)."

He then goes on to suggest more elaborate schemes for cases in which access to 3rd party software is desired.

BTW: the above is by way of Slashdot.

Noah

[1] http://insanecoding.blogspot.com/2013/03/oauth-great-way-to-cripple-your-api.html
[2] http://tech.slashdot.org/story/13/03/22/1439235/a-truckload-of-oauth-issues-that-would-make-any-author-quit

[Michiel B. de Jong]

i'll take this opportunity to mention 3 considerations regarding OAuth
and unhosted web apps:

1) For remoteStorage i think OAuth implicit grant flow is still the
right choice. we don't generally use client pre-registration and so we
ignore the client_id parameter, identifying apps by the origin
(protocol/host/port) of their redirect_uri instead. This is because
generally the storage provider has no idea of which apps the user will
want to connect with, and also it's not generally the storage provider's
job to whitelist apps.

2) Unhosted web apps can also use OAuth to connect with for instance
the Flattr api, because that api offers implicit grant flow OAuth and
CORS headers on the api itself. you do generally have to register your
app's redirect_uri with the service, so that the service knows who
developed which app. This means the app cannot easily be mirrored
anymore, but otherwise this is not a big problem.

3) However, some APIs (dropbox, github) offer OAuth 1, with client
secrets. github explicitly tell you never to publish your client secret,
which is probably a way for them to trace the origin of their api
traffic, in case they need to selectively shut it down. this stems from
the "hosted software" paradigm, where the app that connects with the api
runs on a server.

i'm creating functionality for the "Terms of Service; Didn't Read"
website (which is an unhosted web app) where a user can submit pull
requests once they OAuthed to github. I'm inclined to simply publish the
tosdr client secret inside the app, rather than hiding it in a proxy.

Dropbox, in their dropbox.js documentation, advise you to publish your
client secret. This sounds a bit weird but it makes sense for unhosted
web apps. see also
http://stackoverflow.com/questions/6737918/oauth-embedding-client-secret-in-your-application#6766574

the point is, if you hide the client secret in a proxy, then it's
effectively the same thing, an attacker could still do bad things to
github and make github think that our app has something to do with it.
you could limit the things such a proxy would allow through, but
otherwise, the api should probably just be protecting itself against
what a user sends it. there would also be little incentive for an
attacker to use our client secret, because it's very easy to obtain one
directly from github (easier actually than prying it out of our source
code).

For comparison, NimbusBase also publishes the dropbox client secret in
their sample app, so this would be comparable to that set up.
https://github.com/winterlightning/tweetdiary/blob/gh-pages/dropbox.js
But i'm still a bit afraid to get this wrong, especially because unlike
for dropbox, the documentation for github is so explicit in forbidding
it, so i will think it through some more, and maybe i'll use an
unbranded app registration, so that the brand is not affected if someone
would use it for malicious purposes.


Cheers,
Michiel

[Jan-Christoph Borchardt]

Just mail and ask Github what the reasoning behind that advice is. Better than speculation.

--

--- You received this message because you are subscribed to the Google Groups "Unhosted Web Apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to unhosted+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michiel B. de Jong]

On 2013-03-25 16:01, Jan-Christoph Borchardt wrote:
> Just mail and ask Github what the reasoning behind that advice is.
> Better than speculation.

ah good idea, i did, and here's what github tech support said about it:

> Combined with DNS spoofing, such a redirect could be dangerous, but a
> much simpler abuse would be to use your app's credentials to create
> tokens tied your app [1]. These would use your rate limit, and make us
> think possible nasty behavior could be coming from your application.
>
> [1]: http://developer.github.com/v3/oauth/#create-a-new-authorization

So i guess the downside is that the service provider then has to rate
limit their API per IP address instead of per client secret. Or they
might just automatically block your client id when they see traffic
coming from too many different places.

[rhapsodhy]

Sorry for joining this discussion so late, but looking into
authentication/authorization lately made me think about this. Also,
sorry for the length.

I agree that Oauth 2 is currently as good as it gets for
remotestorage. I still played with the idea of BrowserID and
Tahoe-LAFS, and I would like to hear your opinion on these thoughts.

BrowserID support would be interesting, as ideally that would be
provided by the browser, possibly stripping some of auth code from
remoteStorage. It would, on the other hand, not provide authorization,
and I have no idea how well it is supported on mobile platforms.

Since BrowserID doesn't have authorization we need something that
handles that. Hooking up remoteStorage with a backend like Tahoe would
make this interesting. For those not familiar with Tahoe, it is
a distributed document store. Accessing documents is done through
cryptographic keys, a separate one for read and read-write operations.

Users of a remoteStorage could request access to other users'
resources, and share stuff easily inside Tahoe. Users could also share
their storage and use individual remoteStorage gateways to it, making
the whole network easily expansible. This is not a hack, as in Tahoe
encryption and storage are different services by design.

The permissions the client has could be tracked inside a special node
in the remoteStorage filesystem (like /public/), conveniently mapping
human-readable resource names to the encrypted keys. I'm not sure
what's the best way to exchange of tokens between users, but through
a shared secret they could talk to each other.

Building a stack like this would significantly increase the
server-side complexity, but would integrate remoteStorage nicely into
a crypto-cloud, making it an ideal service a network of FreedomBoxes,
laptops, or even mobile phones, where a user's set of devices would
provide shared storage.

Do you think it's feasible to implement bits and pieces with the
evolution of the standard? I have not dug too deep into the
client-side code, but I think simple modifications would be needed in
the standard, keeping it easy to implement without the crypto-blabla.
Am I overcomplicating this and there is an existing alternative for
this sort of thing?

rhapsodhy

Michiel B. de Jong (2013. Mar. 24. 21.M):
> Date: Sun, 24 Mar 2013 21:13:31 +0800
> From: "Michiel B. de Jong" <anyt...@michielbdejong.com>
> To: unho...@googlegroups.com
> Subject: Re: [unhosted] Fwd: Interesting critique of OAuth by one of its
> creators
> User-Agent: Roundcube Webmail/0.7.2