On Thu, Sep 12, 2013 at 11:31 AM, Petr Bena benapetr@gmail.com wrote:
Sounds cool. When is it going to be available for developers on production?
OAuth2 (which Tyler was referencing) will not be implemented in the next few months. It's unfortunately a fairly complex implementation, that requires making security tradeoffs that I wouldn't feel comfortable rushing.
Anomie and I were talking last night about possibly allowing Consumers to flag themselves as desktop apps that we'll tag with a generic tag instead of a consumer-specific tag. That would take a step towards possibly even allowing desktop applications to register themselves over the api using the user's credentials, send the user through the normal authorization flow to approve the consumer that they "own", and basically make a simple process to essentially exchange their username/password for an authorized token.
This of course means that we would condone users giving their username/password to a potentially trojaned desktop application, for the benefit that honest apps would be able to easily store a token instead of the username/password combination and prevent a later attacker from getting full access to a user's account through their password.
Does the community feel like that's a reasonable tradeoff?
On Thu, Sep 12, 2013 at 8:03 PM, Tyler Romeo tylerromeo@gmail.com wrote:
On Thu, Sep 12, 2013 at 12:00 PM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
I'm personally still not clear on how OAuth 2 solves this problem, unless it's just by saying "you must use HTTPS, and don't assume that the consumer secret is really secret". Which we could well enough do with our OAuth 1.0a implementation, couldn't we?
It does so by not using the client secret in the first place. Keep in
mind
that client authentication is made to solve a very specific problem in OAuth: authorization grant and refresh token security. If you think about it, there's no big need for client authentication normally: resource
owners
have to explicitly grant access, so clients are acting on the resource owner's behalf in the first place.
The main time client authentication becomes important is in the case of authorization grants, because they are secrets that are transmitted over the network to the client, and thus may be subject to compromise. Since client secrets are not transmitted over the network (assuming you're not using the bearer token authentication), they allow verification that the client actually owns the authorization grant in question.
The same goes for refresh tokens, and refresh tokens allow basically unlimited access, so if they are compromised it's a much bigger problem than if an access token is compromised. The purpose of client authentication in the case of refresh tokens is to make sure even if a refresh token is compromised, the attacker would still have to obtain the client secret before being able to use it. The other reason is to enable rotation of client credentials, which would otherwise require revocation
of
all the client's refresh tokens.
Getting to the actual question, OAuth 2.0 uses the Implicit authorization flow for desktop and browser based applications. This flow does not have authorization grants, and does not allow refresh tokens, so all of the reasons for client authentication are moot. Also, unlike other clients, desktop-based clients are within the user's control. So unlike an
external
client, where the only method the resource owner has of controlling it is to revoke it at the authorization server, the resource owner can just
close
the application and be done with it.
Of course, this is not perfect. There is still the attack where the
access
token itself is compromised, or where a rogue client gives access tokens
to
other clients. The latter case is mitigated by the fact that access
tokens
are short-lived, so the application with only have access for a brief period of time (not much of an excuse, since you can do a lot in an hour, but nonetheless better than persistent access). But keep in mind the user decided to trust the application in the first place. The former case is mitigated by TLS, since there really is no other way of protecting nonce secrets other than just encrypting them.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science www.whizkidztech.com | tylerromeo@gmail.com _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l