I've been reading over various OAuth related specs and resources.

Some interesting things I learned while reading up:

== Clients cannot be trusted with security == As far as SSL/TLS goes, this doesn't provide OAuth with as much security as one might think. The whole "SSL is broken" factor aside (You know, all the flaws with CA's and whatnot; https://www.youtube.com/watch?v=Z7Wl2FW2TcA if you fell like watching something you might not have). It looks like app's cannot be trusted with something as /simple/ as actually verifying that they are talking with the right server (You know, that MITM protection that was the whole point of OAuth using HTTPS)

3 point on that: - It seems that the CA root trust setup is not setup by default on various servers and isn't necessarily very easy to setup - In php's default settings for ssl:// and https:// the default for verify_peer "False". In other words, by default https:// connections made using PHP's native code is no more secure than http:// - App developers often run into cURL throwing an error saying that a ssl certificate is invalid (because of the first point, no root certs setup on the machine). When this happens, the reaction of many app developers is to set verify_peer = False. In fact, there are people that go around and RECOMMEND this when people ask for help.

If you want some more reading on this topic, these two articles are good: http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls... http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/

Considering this point on security and the fact that we're not using a proprietary API and discoverability is eventually going to be a big thing for us I think that when we implement OAuth we should make use of signatures mandatory for clients. We can still allow bearer tokens to be used during development. But impose extreme rate limits on them to prevent abuse in production (ie: rate limits more restrictive than api anons currently get).

== We can't always guarantee OAuth authorizations really come from a client == OAuth has the notion of a client_id and a client_secret. There are two types of clients, "confidential" ones like those on hosted servers, and "public" ones like client-only web apps, desktop, and mobile apps. public clients don't get a client_secret because it's impossible to keep a secret a secret when you hand the entire app over to every user that wants it. Hence when it comes to public clients you cannot guarantee that when a user authorized an app the app was actually the app it says it is.

It means for example. That en.wp could suddenly see bot spam that says it was made by the anti-vandal tool "Huggle". Because Huggle would be a public client and the client_id would be public so any random client could say it's Huggle when a user authorizes it.

This means a few things for us: - We should make the difference between an edit made by a confidential client and one made by a public client visible in the UI so editors know the difference. - We shouldn't delude ourselves into thinking we can mass-revert based on client_id when said client is a public client. Instead we should forget that whole idea and allow admins to see individual authorizations given by users to public clients and let admins select whole swaths of them and mass-revert them all at once. - Under that thought. Since we're going to go to the trouble of building tools to mass-revert. Perhaps we should take that extra step and make it a general mass-revert tool. The filtering capability isn't as hard as the revert handling. Instead of just client_id and authorization we could let admins mass-revert a selection of users.

== OAuth is a pretty loose protocol == OAuth actually leaves a lot undefined: - The actual verification of a user is completely outside of the scope of the spec. So it doesn't care whether you make the user login normally or use some sort of web based device flow within the login system itself to let web based mobile applications get OAuth grants using the normal Authorization Code Grant flow but the user themselves get to feel like they are using a device flow. - Getting a token and using it are defined separately. Enough that you could go out-of-spec and write a different method of getting a token. In fact instead of making you tweak sections of the OAuth protocol as you would in OAuth 1.0 the OAuth 2 spec has a section on "Extension Grants" that allow you to specify new methods of getting auth_tokens which you can use to create a new flow. - While some application flows are defined by the spec you still have room to implement new types of flows if you have a use-case for it. - Discoverability is completely out of scope of the OAuth spec. You have room to develop your own pattern of discoverability. (And with signatures you might even be able to come up with a way to make wikis run over http:// secure enough to use OAuth)

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]