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-ssltl…
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]