Comments on: A Different Model For Web Services Authorization

By: Flickr API security weakness, and thoughts about web APIs in general - Yes/No/Cancel

Mon, 26 Jan 2009 19:52:03 +0000

[...] proposed an approach to authorisation in which users explicitly authenticate actions, not applications; any changes made by an [...]

By: Alex Graveley

Alex Graveley — Fri, 09 Jan 2009 18:50:30 +0000

It doesn’t really buy you much in the desktop access scenario. A malicious app can still look at user’s cookies & fake the correct authorization request. You could require a full login at every authorize, but that pretty much breaks any Just Works user perception, which is a strong motivator for these sorts of apps.

By: cal

cal — Tue, 06 Jan 2009 17:27:56 +0000

this doesn’t work well, as you say, for things other than upload. and it means that you need a mobile web interface for any mobile applications that want to support flickr. and it means devices without a web browser (digital photo frames, etc) are screwed (they can do initial auth using mini-tokens – see the flickr api docs).

but on top of that, it just makes things harder to use. and so the site which provides an api that just works, as opposed to one which (in practice) allows you to queue up actions to do later on the site, is going to fail. easy to cite twitter’s success, even though they don’t support any kind of secure three-legged auth.

we’re going to have to always (for the time being, until computers are magical) rely on the user anyway – if they install random binaries then they’re open to cookie stealing and spoofing anyway, so APIs are moot. so the confirmation-before-issuing-user-tokens seems the correct approach (ignoring that flickr’s has been broken lately *cough*).

By: Coda Hale

Coda Hale — Tue, 06 Jan 2009 17:13:15 +0000

I like the idea of a sandbox for changes made by potentially malicious third-party clients, but I think this model is pretty specific to services which have few or large changes, like Flickr. Using this model for Twitter, for example, would be infuriating; the amount of data a client sends isn’t over the “let me review this before it goes live” threshold. Where it does apply, however, I think it makes perfect sense — I’ve often wanted a review stage for my Flickr uploads.

By: Nick

Nick — Tue, 06 Jan 2009 15:34:45 +0000

I don’t know if this sort of model is sufficient for me to trust third party applications, but I think it’s necessary. It might let one more meaningfully audit pending (and past) transactions – it’s just as valuable for reads as well as writes.

By: kellan

kellan — Tue, 06 Jan 2009 12:48:30 +0000

Ian, first you need to establish your security constraints, then you can evaluate if a proposal meets them.

In the case of single purpose, trusted origin installed software like the Flickr Uploadr you could make a case that the single most secure option is username-password/ClientLogin over SSL. (we don’t, and we’re comfortable with that choice made for a combination of technological, policy, and customer care issues)

And for the above submitted changeset approach above, when used in a hosted web context sounds like a XSSers dream.

So first, the problem space.

By: Blaine Cook

Blaine Cook — Tue, 06 Jan 2009 09:12:02 +0000

Watching NetFlix on my XBox would be extremely irritating if I had to go to my computer to authorise my XBox to download or rate a movie. This might be a good approach, as you said, for Flickr, but I’m not sure it has enough general applicability to supplant current models of delegated auth.

Also, implementing change sets like that would be a total pain in the ass on the server side.

By: No More Secrets | Software and Opinions

No More Secrets | Software and Opinions — Tue, 06 Jan 2009 08:03:25 +0000

[...] Software and Opinions from Ian McKellar Skip to content About « Closed Source A Different Model For Web Services Authorization » [...]