On Sat, 14 Jul 2012 06:09:54 -0700, Niklas Laxström
<niklas.laxst...@gmail.com> wrote:
On 14 July 2012 11:30, Daniel Friesen <li...@nadir-seen-fire.com> wrote:
I've been reading over various OAuth related specs and resources.
Some interesting things I learned while reading up:
Can we have TL;DR version too? Anything else than "there are many
problems with OAuth"?
-Niklas
Ok, TL;DR version:
Facts:
App developers cannot be trusted with security. HTTPS when used by app
developers is regularly no more secure than HTTP. Certificate stacks are
regularly unconfigured. PHP's own default for HTTPS is to let anyone
impersonate a website. And app developers are regularly stupid enough to
disable verify_peer (let anyone impersonate a website) themselves and
RECOMMEND this to other people when they ask for help.
Conclusion:
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).
Facts:
We're going to have people using 'public' OAuth clients. We cannot trust
that aythorizations made to public clients really come from that client.
Conclusion:
We should ditch the idea of mass-revert by OAuth client_id for public
clients. Instead we should take the extra step to make our mass-revert
tool work as a general mass-revert tool. And we should give admins the
ability to select large swaths of individual authorizations to a public
app (instead of the whole client_id) and let the admin mass-revert all the
ones they selected at once. We should also let users see the difference
between a confidential and a public client inside the UI.
Last musing:
OAuth is quite loose. We have a lot of room to implement our own custom
flows, apis, etc... Two ideas I find really interesting:
- Including a sort of web based device flow into the login page when you
are doing an OAuth authorization. This would mean that if you're using a
web app on your mobile device when you are sent to MediaWiki's login page
you'll have the option of doing a device authorization instead of logging
in with your password even though the web app probably will have only
implemented the normal Authorization Code Grant flow.
- Discoverability is completely undefined by OAuth. I think we can
implement a discoverabiliy + convergence like trick + signatures to make
it possible to use OAuth over wikis that only use http:// secure enough to
use.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
