On Thu, Sep 12, 2013 at 12:00 PM, Brad Jorsch (Anomie) < [email protected]> 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 | [email protected] _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
