On Sat, 14 Jul 2012 06:09:54 -0700, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 14 July 2012 11:30, Daniel Friesen lists@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.