Hi Chris, On 22 October 2013 05:45, Chris Steipp <[email protected]> wrote:
> OAuth does not support this, since the results of an api call > using OAuth signatures aren't signed (only the request from the OAuth > consumer is signed), so it's possible that an attacker could forge a > response back to the application, and the application would think a > different user was logged in. This is less likely if you're using https for > your api calls, but it's surprisingly hard to get https right [1], even if > you trust all your CA's. > (...) > > This is a common issue is being addressed by the OpenID Connect extension > to OAuth2, which allows the application to request information about the > person doing the authorization, and the result is signed by the server to > prevent tampering. (...) I'm a bit confused by this -- I was under the impression https would be enough to confirm I'm actually talking to the WMF's servers. The main argument in [1] against just using https seems to be it's easy to ignore invalid certificates. Is there another reason why it's dangerous to assume you're talking to mw.o if the certificates check out? Basically, I'm not quite sure whether using OIDC will help alleviate this problem - you get a response back, but you still have to check the signature! And with the ease of not checking the signature, you're basically back to the same problem with not checking the ssl certificate. Nonetheless, I think it's useful to add an authentication mechanism that follows a standard - which is clearly not the case with the current 'api.php?meta=userinfo' calls. Merlijn [1] http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/ _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
