On Thu, Sep 12, 2013 at 11:31 AM, Petr Bena <benapetr(a)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(a)gmail.com> wrote:
On Thu, Sep 12, 2013 at 12:00 PM, Brad Jorsch
(Anomie) <
bjorsch(a)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(a)gmail.com
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l