RESTful and user-centric authorization in OAuth

OAuth is a protocol for delegating access via APIs.

It has some complexity in the protocol which can be discussed, but some concerns are:

• state, there are nonces and multiple types of session tokens to keep track of
• no-sharing, no easy way of sharing authorization tokens between systems: each token is only usable within its issued system.

We can think about authorization in a RESTful and user-centric manner and create tokens independently from consumers and service providers. A user should be able to create a token and pass it to any and several service provider, which should be able to parse and act on it.

I picture a way to do this is to specify a unified token format that contains:

• A set of actions (GET/POST/PUT/DELETE) + resource identifier (URL)
• A set of recipients (URLs)
• An optional validity interval of this token
• A set of creator identities (URL) + creator signatures of the token

The resource identifiers may contain wild-cards (not sure: to be discussed to be usable)

A token to give Alice the right to post on this blog could then look roughly like

  recipients=http://alice.example.com
  actions=POST,http://commented.org/posts
  from-validity=2008-04-28Z
  to-validity=2008-12-31Z
  creators=http://commented.org,eW91IGhhZCB0byBsb29rPwoK

The resulting token could then be freely exchanged, and publicly posted if desirable. Encryption of the token may be feasible. A service provider should be able to parse the token and accept it if it’s properly signed by an acceptable creator.

The tokens now contain all the state information needed and can be cleanly passed around. Also, the standardized token format means service providers can present a common, unified UI to end-users, and there is no specific lock-in to any protocol — you could distribute the tokens through email if you wanted to.

Any thoughts?

Comments

[Chris Messina]

Ok, I understand this idea better now. I like it, but I'm not sure how to fit it into the OAuth worldview.

Another way to talk about this, which I've been throwing around, is the idea of revisions, of "take backs" -- of the ability to undo actions taken with certain tokens in the case that an authorized system is compromised and messes up your account... In that kind of situation, being able to undo ALL actions taken with a specific token becomes very valuable (think about wiki defacement). If all actions that were taken were portable, as discussed here, you might imagine the benefit of developing a widely supported mechanism or protocol for taking "tokenized actions".

It would maybe help if you could develop a demonstration of this concept, because I think I get it, but seeing running code would help a whole lot more! :)

[Hans]

Token revocation is interesting. I sketched out an idea a while back, http://commented.org/blog/2007/2/12/crypto-less-assertions-defined.html ,to do crypto-less assertions. Maybe one can build on that and have each token point back to its verifier ("this token can be verified at <https://example.com/token/1234>") and then a token is only valid if the SP retrieves that URL and gets back the exact same token.

I agree with necessity of code. I will look into it.