Simpler OAuth For Lower Risk Use Cases

Conference IIW8 Room/Time: 9/J

Convener: Brian Eaton, Eric Sachs

Notes-taker:

Attendees:

Technology Discussed/Considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Basic problem: OAuth is really hard to implement. That's a common complaint we hear from developers who want to be OAuth consumers.

Some proposals to simplify OAuth to increase adoption:

• Simpler base strings
• Unregistered OAuth
• Simpler base strings

We could make the base string such that it's just tied to the nonce, timestamp, consumer key, token. The idea is that you sign these values and they're good for only a certain amount of time.

OAuth access tokens never change. Thus, we can't really do PLAINTEXT signatures because that would cause the access token be sent over the wire. OAuth session extension simplifies the signing (because we can get away with not signing) but complicates the session protocol. It's hard to bake the protocol flows into the libraries today. It's much easier to create a simpler base string. An OAuth SP could have a policy saying that as soon as the user signs out of the SP site, the access token granted to the consumer is revoked. That would prevent the access token from being "all powerful" forever.

The whole value of OAuth is to enable the consumer to access data in absence of the user. Major thing that trips people up: People cannot figure out how to sign a request.

Unregistered OAuth: Saves developers from having to register consumer keys and secrets. Even with unregistered OAuth, you're still required to sign requests. So, this doesn't some your problem. It could be hard to get away with this from a legal standpoint. We could have an automated way to get a consumer key and secret. (see notes from the session Angus led yesterday) The problem isn't necessarily the complexity of the protocol. If we could provide good libraries. Plaxo provides HTTP Basic auth so that developers can experiment, but this is really simple.

What do you do when the SP returns a 302? Some of the problems go away if you use the simpler base strings (just CK, token, timestamp, and nonce). SBS approach would include no URL encoding What's the problem with libraries?

• Every service provider is a touch different.
• Most of the extra security that we added to OAuth is to make it possible to provide security for SPs who don't want to setup SSL. Perhaps all these extra stuff are more difficult than just setting up SSL.

We have a choice: We can implement the scalable OAuth session extension or can try to really simplify signing.

Alternative proposal: If we just said HTTPS is mandatory for SPs, then we could really simplify OAuth. For a typical website, all devices from which the user signs in must support HTTPS. Either HTTPS would have to be used on both the authentication server (i.e., the OAuth dance part) and on the data API server, or HTTPS would have to be used on the authentication server and the session extension would need to be used with the data API server. This is no less secure that sending session cookies via HTTP and using those session cookies to authenticate the user. If we require HTTPS, we can just use a plaintext signature or completely eliminate the signature. If we said "scalable session extension with PLAINTEXT signature over HTTPS", how hard would that be? Or just pass along the access token. Have the consumer periodically refresh the access token and stick it in the header. A developer should be able to use curl() to get this to work.

Proposal: PLAINTEXT + Session Extension Long-lived session handle goes to accounts system over HTTPS Short-lived access token goes to services (optionally without HTTPS) No signatures, timestamp, or nonce ever on any step. Dance always over HTTPS without consumer secret. This would be OAuth if you can mandate SSL. Accounts system will return a long-lived session handle and a short-lived access token. When the short-lived access token expires, you have to go back to the accounts system and present your long-lived session handle to get a new short-lived access token.