Design rationale? - OAuth

Message from discussion Design rationale?

Hans Granqvist

More options Apr 9, 1:26 pm

From: "Hans Granqvist" <h...@granqvist.com>

Date: Wed, 9 Apr 2008 10:26:06 -0700

Local: Wed, Apr 9 2008 1:26 pm

Subject: Re: [oauth] Re: Design rationale?

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

> > For example: There are seemingly seven protocol flows to do an
> > authorization. The tokens travel long ways: First a party requests a
> > token, then passes this token to the end-user for authorization, then
> > gets it back and exchanges this token for another token that is then
> > used to gain access to resource.

> Which step in the protocol do you think you can eliminate, and how?
> I've convinced myself that all of the requests are necessary for the
> general case, but I'm certain there are short cuts for specific
> consumer/service provider relationships.

I'm curious why there is a need to exchange the request token to and
access token. The initial request for a token (6.1.1) is authenticated
by the consumer and the request is outside the user's reach.

It seems the returned token should carry enough state to make
subsequent steps 6.3.1-6.3.2 superfluous: in other words, the consumer
should be able to access a protected resource with the original token.

My reasoning here is that there is seemingly nothing added to the
token itself as it is replaced to an access token. There is still
a single service provider with the need to do the same lookups
for token validity.

Hopefully I'm wrong and I'm missing something. Regardless, some
discussion why the steps are needed would help. Since you're already
convinced, perhaps we could create a straw-man page capturing why a
each step is required?

> > This may not be part of the problem to solve, but what seems to be a
> > common use case is that a User wants to 'pre-authorize' a Consumer
> > access to some Protected Resource. Is this possible using OAuth?

> This is an interesting question. In theory if a consumer and a
> service provider can agree on a way to exchange pre-authorized request
> and/or access tokens, this should work. There are two hurdles
> involved:
> 1) How do the consumer and the service provider know which user they
> are talking about? In the general case, user X...@consumer.com can
> correspond to any user Y...@serviceprovider.com. This is why the
> protocol involves the user visiting both the consumer and service
> provider applications in quick succession, to allow the identities at
> each to be correlated.
> 2) How do they handshake on the value of the pre-authorized access tokens?

> Those are not insurmountable problems, but they don't seem to have
> general solutions. As one example of a specific solution, imagine
> this:
> - user visits service provider, clicks a button saying 'give this
> photo to printer.com to print'
> - service provider redirects user to printer.com with a pre-approved
> request token in the redirect URL
> - printer.com exchanges the pre-approved request token for an access token

There are ways to define a set of operations and a set of subjects, objects,
and so on. If we can assume that principals (i.e., the protocol
parties) all have
unique identifiers, and that the set of operations can be defined (action +
time span + ...) on resources (with OpenID style trust realms, perhaps), then
all this could be encoded in a structure that can be appropriately signed ahead
of time. A very simplified example could be

"grant http://serviceprovider.example.com read on
http://resource.example.com/alice/* from <timestamp> until <timestamp>"

that Alice can create ahead of time and sign. The service provider then
does not need to involve Alice to get authorization, but merely make sure
the request 'matches' the pre-authorization.

You're right. It's not trivial to build.

> ...
> > But putting those protocols aside, there have been several other
> > methodologies over the last decade or so to deal with roughly the same
> > problem OAuth tries to solve. For example, Kerberos, but also
> > network-based capabilities, etc. spring to mind.

> Kerberos doesn't seem to do anything remotely connected to OAuth. You
> see Kerberos used as an authentication protocol within a single
> identity silo. OAuth is an authorization protocol for use across
> identity silos.

Check Kerberos multi-realm which addresses cross domains authentication.
No idea how widely deployed it is, but there are a few nice theory write-ups
behind the idea.

OAuth, on the other hand, actually seems limited, at least in the way the
spec is written, to a single service provider in that the provider issuing the
request token must be the same provider ultimately issuing the access token.
But perhaps I'm misreading?

> No comment on "network-based capabilities", I'm not sure what you mean.

Think capabilities-based security[1] in a network setting. The thing you have
contains the rights to use it. In my idea of a simplified networkable
capabilities system, access to the thing + correct signatures on it =
the right to use it.

Some interesting ideas from the Java security model + the JECF gateway
capability security model[2] springs to mind. (I know [2] is old, but it's
a pretty cool idea ;)

> > I'd love to have a solution where the tokens passed around are not
> > "just" signed blobs, whose formats are defined by each service
> > provider, but blobs whose formats could be standardized to carry
> > semantic information about resources, rights, privileges, etc., that
> > can possibly be shared between disparate Service Providers. Any
> > thoughts on that?

> Sorry, you lost me there. Can you be more specific, maybe offer some use cases?

Does the simplified "grant..." scenario above help?

> Cheers,
> Brian

Hans

[1] http://en.wikipedia.org/wiki/Capability_%28computers%29
[2] http://www2.sys-con.com/ITSG/VirtualCD_Spring05/Java/archives/0307/so...

Reply to author Forward