Sounds cool. When is it going to be available for developers on production?
On Thu, Sep 12, 2013 at 8:03 PM, Tyler Romeo <[email protected]> wrote: > 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
