OAuth, the good parts

[Eran Hammer]

What parts of OAuth 1.0 and 2.0 do you like? What should we keep? What’s been the main pain points for you?

 

EH

[Coenraad Loubser]

By the looks of it you've written volumes on the subject - which I will catch up on. But how about a headline summary here, reiterating the best and worst bits in your opinion?

[Christopher Biscardi]

Tumblr back in the day had a PITA OAuth situation for uploading photos. It was 1.0a based and had something to do with the differences between encoding on the server and encoding on the client. I had to write my own library to interact with the api and there was no "here is a valid request/response for photo uploading".
That could probably be solved with example code. At least then a dev could set up a server locally and examine the requests (npm install -g oz-server. oz-server run). "Black Box" and Implementation Fragmentation are huge headaches.

I think we should prioritize ease of use (which seems to already be the case). Devs shouldn't need to be crypto experts to use a library.

CB

[Kevin Mutyaba]

OAuth 1.0

Keep:

- Token signing

This was quite painful to get right in the past. However, after my experience with OAuth 2.0, I have come to  appreciate having the signing process. Making it easier would be good though

Pains: 

- OAuth 1.0 was tied to the web browser and was difficult to implement on installed applications. You had the PIN system from Twitter and XOAuth wchich kinda mitigated the problem. However, OAuth 2.0 addressed this to some extent

OAuth 2.0:

Keep:

SSL

         One of the many layers of security that should exist

Multiple authentication grant types i.e Implicit grant for session based tokens, Authorization Code for persistent tokens, Resource owner credentials for native app

More especially, having a cleaner flow for native applications and multiple devices. OAuth 2.0 and 1.0 do not address authentication flows for clients that do not have browsers. Google tried to account for this my creating a user code endpoint for such devices but, it would be great if we could consider those too.

Token Scoping:

How token scoping is don't may not really factor into the protocol. However, i think the code should include something of the sort to let people know that scoping tokens is important. 

Pain points:

- Difficulty in protecting client credentials

 It is impossible to keep access tokens protected in the case of native applications however, you already know that. When you deploy a native application, all installations of the application will have the client_id and secret hardcoded somewhere in the code for the sole purpose of authenticating the user later on. The problem with installed apps is that they are vulnerable to reverse engineering. In fact in the case where clients do not validate the SSL cert, you can intercept the credentials just be looking at the HTTP traffic (I have been able to do this quite easily on iOS using Charles) As a result the client credentials can easily be retrieved and used to create a spoofed app. If the spoofed app were malicious, it would be impossible to track it down and the only way to stop it would be to deploy a new app with a new set of credentials which would subsequently get discovered again. 

My thoughts about solving this problem were to include a new per-installation ID that would used to keep track of each native app installation. In the event of a rouge app, it would be easy to just revoke the per-installation ID of that app instead of kill all your already deployed app installations. This in no way solves the problem of protecting client credentials however, it does make it easier to handle the aftermath of a compromised natvie oauth2 client.

i guess another way to protect against this would be to sign your native app code so that only native clients whose signatures match are allowed to go through the authentication steps. I imagine that this would require a third party such as the app store and android market place to actually keep these signatures (probably will not happen so, I guess it does not matter)

In any case, I would like to have a way to protect any credentials that should not be leaked to unauthorized parties or atleast a way to make authorization possible with out having to use credentials whose secrecy is paramount to preserve all installed native clients. 

- Webviews in native apps

You have already touched on this many times but I'll put it here anyway. The flow for getting third-party native clients authenticated is absolute total crap and painful to implement. The web-views are meant to prevent the third parties from getting access to user's credentials however, given that you can easily intercept input from the webview and access the user credentials, this a absolutely pointless do to in the first place. So, in effect it is impossible at the moment to write a library for third parties to use that will allow them to get user authorization without putting the users' credentials at risk of being intercepted.

This is all I have for now. Native apps present the biggest problem but, then again that's why you are working on Oz. I hope this helps

On Friday, October 26, 2012 10:46:20 AM UTC-7, Eran Hammer wrote: