Log in

No account? Create an account

Previous Entry | Next Entry

Over the weekend I took a quick stab at what a new draft of an OAuth 2.0 spec would look like. I don't have a lot of normative text but wanted to share what I was thinking about in terms of the specification's structure and technical inner-workings.

This comes out of the survey from two weeks ago which Peter Saint-Andre summarized as there being consensus around:

  • OAuth 2.0 taking aspects from both the 1.0 and WRAP specs/drafts with a preference toward the WRAP draft
  • we should go back to working on a single document
  • OAuth 2.0 should support signatures as a mechanism for making requests

Documents involved:

  1. OAuth 1.0: http://tools.ietf.org/html/draft-hammer-oauth-10
  2. WRAP: http://tools.ietf.org/html/draft-hardt-oauth-01

Combined document structure:

My goal is that sections one through four are not more than fifteen to twenty pages combined.

0. Abstract

1. Introduction
1.1 Acknowledgments
1.2 Terminology
1.3 Notational Conventions

2. Getting an Access Token
2.1 Web App / JavaScript Profile (in browser)
2.2 Rich App Profile (can open a browser)
2.3 Device Profile (no browser, should be like the Netflix flow)
2.4 Username and Password Profile
2.5 Client key and secret (not in the context of a user)

3. Refreshing an Access Token

4. Accessing a Protected Resource
4.1 Using SSL
4.2 Using a signature

5. Security Considerations


OAuth 2.0 provides a method for an application (Client) to access the Protected Resource hosted on a server on behalf of a Resource Owner (such as a different client or an end-user). It provides a process for end-users to authorize third-party access to their Protected Resources via a variety of Authorization Profiles which generally do not include having to share their credentials (typically, a username and password pair). A server can additionally delegate authorization to one or more authorities (Authorization Server) which issue Access Tokens to Clients.


  • This section should provide a longer description of the protocol flows and the evolution from OAuth 1.0.
  • The terminology should be based on updated OAuth 1.0 terminology which is already close to the WRAP terminology as well. We should err on the side of more generally understood terms.
  • Both OAuth 1.0 and WRAP contain fairly complete introductory sections. I think that the WRAP one is a bit too long and we should shoot for this section being a little over two pages (including terminology).

Getting an Access Token

  • This section really comes from WRAP. I believe that a server MUST implement at least one of the profiles to be considered OAuth compatible.
  • The updated OAuth 1.0 spec could also be useful for more complete language around the Web App Profile though we should also draw from Luke Shepard's JavaScript profile (which needs updating). I believe the main difference is the security characteristics.
  • While the SAML assertion profile has been in WRAP, I haven't seen strong advocates on the mailing list or in the survey for it. Does someone want to argue for keeping it? Could it be drafted as a separate profile from the core spec?

Refreshing an Access Token

  • In WRAP this functionality is described along with each individual authorization profile. Some profiles require the client id and secret though not all of them. In terms of writing more reusable code I imagine that implementors will write a single refresh_token(client_id, client_secret) function so breaking this out into its own section will be easier to implement.
  • We could either require the client id and secret for all profiles or keep them as optional for some profiles. Personally I lean toward consistency.

Accessing a Protected Resource

  • This section is really a combination of WRAP and OAuth 1.0. SSL support will be a MUST and signatures will be optional.
  • Bearer tokens (even short lived) without using SSL or signatures feels like a poor idea, but given the WRAP draft it seems like the security teams at Google, Microsoft and Yahoo! are all comfortable with doing so? Given that we'll be adding signatures as an option do we still need unprotected bearer tokens?
  • The SSL section basically copies directly from WRAP section #4. It's about a page and a half and really easy to implement.
  • We need to agree on the signature method though there is a lot of normative text in the OAuth 1.0 spec to draw from. OAuth 1.0 is about three pages of text assuming people are happy with the mechanism; it would be good to simplify as much as possible.
    • We're missing an access token secret, but I'm wondering if we can treat the refresh token as the access token secret since it's only sent over the wire via SSL?
    • Alternatively we could modify the refresh token request to let the client specify that they'd also like an access token secret for that request. This seems like the right way of doing it.
    • Both break the idea that the API endpoint doesn't have access to secrets, but the deployment scenarios I've seen discussed as wanting signatures (at least Facebook and Twitter) won't be separating their architecture anyway.

Security Considerations

  • I'm the wrong person to write this section.


  • Rename parameters to oauth_

If I were to spend some time over the next week or two drafting this spec would folks generally be supportive of it? If not, what would you change so that you could be supportive of it?

One of my goals is getting OAuth 2.0 to the point – fairly quickly – where we can start to architect the next version of OpenID on top of it. WebFinger + OAuth 2.0 + identity would be sweet and finally give us a consistent story for both authentication and authorization. I'd love whatever help I could get with all of this as well!

Cross posted to the OAuth IETF mailing list



( 9 comments — Leave a comment )
Mar. 3rd, 2010 10:46 pm (UTC)
If TLS becomes a MUST for any part of running an OAuth server, then many of us (esp in the Wordpress-on-Dreamhost world) will be forced for now to use OAuth 1.0 anyway.
Mar. 3rd, 2010 10:51 pm (UTC)
hmm, OAuth servers on shared hosting hasn't really been represented so far. What sorts of things are you doing where you're running an OAuth server on Dreamhost?

Also see http://www.ietf.org/mail-archive/web/oauth/current/msg01049.html for a discussion of SSL as the primary means for OAuth communication.
Mar. 4th, 2010 02:45 pm (UTC)
Well, that was originally the whole usecase for OAuth, right? WordPress APIs / etc to allow client logins to self-hosted sites for yourself and/or your contacts. There are a couple OAuth WordPress plugins, thought I'm not sure their status WRT the rapidly shifting OAuth world, though. They're probably all OAuth 1.0 original draft :P
Mar. 4th, 2010 02:47 pm (UTC)
RE: that mailing list post. Totally agree that if the goal is to give the big guys yet another tool that TLS is better. Also, if that is the goal they may want to investigate existing tech like client TLS certs (signed by internal CA) ... pretty easy to set up and tons of benefits.

OAuth to me has always been about shared hosting. The "anyone can implement it" goal. Same reason why GET and POST were in the original protocol... Authentication headers don't go to CGIs :)
Mar. 4th, 2010 06:26 pm (UTC)
I always thought of the goal as allowing shared hosting environments to make OAuth requests though hadn't placed as much emphasis on their acting as servers. Folks should join the mailing list and help represent this use case!
Mar. 6th, 2010 07:54 pm (UTC)

The requirement for application pre-registration and the lack of auto-discovery basically foils any attempt to use OAuth for small things, but it'd be great if you could just use OAuth for talking AtomPub to some arbitrary endpoint with out that... and at that point running an OAuth endpoint on your random WordPress install on some shared hosting makes a lot more sense.

Mar. 4th, 2010 12:15 am (UTC)

Doing short-lived access tokens in cleartext is not really any different to how most sites handle sessions today. A short-lived access token isn't much different than a session key.

However, if access tokens are going to be used in this way it's probably sensible to define a mechanism by which a consumer can explicitly invalidate an access token. This means that an access token can be tied to the live of a site session: when the user logs in (or, when they first do something that needs the access token) use the refresh token to obtain a new access token; when the user logs out, terminate all of the active access tokens associated with that session.

I'm not feeling too strongly about this yet, but I think I have a preference for there being only one model that's well-defined rather than two models. If we support access tokens tied to sessions do we also need to support signatures? Implementors are more likely to get it right if they have less cases to deal with.

Mar. 4th, 2010 06:29 pm (UTC)
An invalidate method makes sense, though wouldn't this just happen by refreshing the token anyway? You'd get a new access token and the old one would stop working.
Mar. 4th, 2010 06:32 pm (UTC)

Maybe that would work, as long as the new access token is known only to the consumer until the next time the user logs in. Obviously the difference with explicit invalidation is that when the user isn't around there are no valid access tokens at all for that user.

( 9 comments — Leave a comment )