There is a session fixation attack against OAuth 1.0.  There is a security advisory.

There have been a lot of mailing list threads on this.  There was a meetup on Friday to talk about the problem. Folks from Yahoo, MySpace, Google, LinkedIn, and Plaxo attended.  We discussed two proposals:

• Signed Callback URLs
• Signed Approval URLs

(A large number of other proposals were discussed briefly, but aren't covered here because they either didn't fix the problem, seemed more complicated, or did sufficient harm to the user experience that we thought they would drive people back to asking for usernames and passwords.  For an exhaustive list of possible solutions, see the mailing list threads from mid-April 2009.)

Comparision of proposals:

Does it work if the consumer application can't read data off the callback URL (e.g. an installed application that doesn't integrate with the web browser in any way)?

Signed callback URLs: yes.  Code is short, user types it in.

Signed Approval URLs: no.  Callback token has to be long, users can't type it.

Does it work if the consumer cannot launch arbitrary URLs (e.g. device with no web browser built-in)?

Signed Approval URLs: no.  Approval URLs are too long.

Signed Callback URLs:  yes.  Consumer displays request token, user visits URL at SP and types in request token.

Does it work if the consumer has no character input (e.g. device with no keyboard)?

Signed callback URLs:  no.

Signed approval URLs:  no.

We need another proposal to handle these devices.  We may need to continue to use OAuth 1.0 for devices that have no keyboard and no web browser available.

What if the device has no display capability (e.g. manufacturer includes request token in instruction manual for device)?

Signed callback URLs:  no.

Signed approval URLs:  no.

We need another proposal to handle these devices.  We may need to continue to use OAuth 1.0 for devices that have no display capability.

Does it support UI enhancements such as language extensions?

Signed callback URLs:  yes.

Signed approval URLs:  yes.

Does it have latency impact?

Signed callback URLs: no.

Signed approval URLs: probably a latency reduction, since there is no request token roundtrip.

Is there a smooth upgrade path from OAuth 1.0 to the fixed protocol?

Signed callback URLs: consumer detects whether SP supports new protocol by sending oauth_callback parameter on request token step and checking for confirmation in SP response.  SPs can be backwards compatible with both old and new consumers fairly easily by checking for presence of oauth_token and oauth_signature on approval URL.  (No downgrade attack is possible.)

Signed approval URLs: consumers must know whether SPs support new protocol.  SPs can be backwards compatible with both old and new consumers fairly easily by checking for presence of oauth_token and oauth_signature on approval URL.  (No downgrade attack is possible.)

Does it work for web applications that can keep consumer secrets, but no fixed callback URLs?

Signed callback URLs: yes, unless SPs require callback URL preregistration.

Signed approval URLs: yes, unless SPs require callback URL preregistration.

Does it work for web applications that can't keep consumer secrets, and don't have a fixed callback URL?

Signed callback URLs: yes, unless SP requires callback URL preregistration.  SPs must identify application by callback URL, not by consumer key.

Signed approval URLs: yes, unless SP requires callback URL preregistration.  SPs must identify application by callback URL, not by consumer key.

Does it work for web applications that can't keep consumer secrets, but do have a fixed callback URL (e.g. desktop app that registers protocol handler or otherwise integrates with browser)?

Signed callback URLs: yes.

Signed approval URLs: yes.

Other comments:

Exotic protocol flows:  Signed approval URLs seems much more similar to OpenID, SAML, BBAuth, AuthSub, and most other web authentication and authorization protocols.    Signed callback URLs is like a combination of those protocols with the OAuth 1.0 protocol.

Large amounts of data on request token step: Signed callbacks allow consumers and service providers to pass large amounts of data on POSTs to the request token URL.  Signed approval URLs hit URL length limitations if large data transfer is necessary.  (Nobody has use cases that require large data transfer prior to authorization, so this seems irrelevant.)

Simplicity:  the signed approval URL flow has fewer steps.  If someone was starting from scratch they probably would rather use this flow for applications with callback URLs (web apps, smart installed apps), and a separate flow for other apps that don't have callback URLs.  On the other hand, the signed approval URL flow requires managing signed URLs in the browser.  Service providers need to be careful not to break the "back" button in the browser.

Security: we agree that the addition of the callback token fixes the protocol.  The lack of the request token step in the Signed Approval URL protocol means that if

• the consumer secret is not secret (installed application) AND
• the service provider or consumer does not use https

an eavesdropper gets all the information they need to obtain an access token.  The same is not true of the Signed Callback URL proposal.  In that case eavesdropping is not sufficient, an active attack where the victim is redirected with the attacker's request token is necessary.

There has been a lot of brainstorming in the past week about possible attacks, with lots of good ideas on things that consumers and service providers can do to make themselves more secure.  We think either of the proposals above will fix the problems in the protocol, which is the most critical thing.  We're going to consolidate the other ideas into a security best practices checklist that consumers and service providers can use.