Hi everyone. I'm trying to find out about the rationale behindsome of the OAuth design decisions.
The spec doesn't discuss this, and I can't seem to find anything on this mailing list (beyond some initial discussions that a rationale indeed is needed from beginning of August 2007), or on the web. Did I miss it?
I'd be willing to start a wiki page or similar. I think it could be quite useful.
That is not accurate. We state in many places that OAuth was designed based on existing protocols and was an attempt to consolidate them. There is a long discussion in the group archive regarding the unification of the three flows (web, desktop, mobile), as well as the decisions about signature methods and parameter passing.
If you have specific questions, just ask...
EHL
From: oauth@googlegroups.com [mailto:oauth@googlegroups.com] On Behalf Of Hans Granqvist Sent: Monday, April 07, 2008 11:55 AM To: oauth@googlegroups.com Subject: [oauth] Design rationale?
Hi everyone. I'm trying to find out about the rationale behind some of the OAuth design decisions.
The spec doesn't discuss this, and I can't seem to find anything on this mailing list (beyond some initial discussions that a rationale indeed is needed from beginning of August 2007), or on the web. Did I miss it?
I'd be willing to start a wiki page or similar. I think it could be quite useful. Hans
On Mon, Apr 7, 2008 at 8:54 AM, Hans Granqvist <hgranqv...@gmail.com> wrote: > Hi everyone. I'm trying to find out about the rationale behind > some of the OAuth design decisions.
> The spec doesn't discuss this, and I can't seem to find anything > on this mailing list (beyond some initial discussions that a rationale > indeed is needed from beginning of August 2007), or on the web. > Did I miss it?
I started off in more or less the same boat as you, looking at a specification that had almost no explanation of why things were done a certain way. It's frustrating, it has led to implementation bugs, and I hope future oauth extensions don't do silly things like tell you to read the appendix just to understand what the spec is trying to accomplish. There is no law that says specifications must be opaque.
Ranting aside, though, I agree with Eran's recommendation: just ask. Almost all of the specification has some reasonable rationale behind it, and there are lots of people on this mailing list who can explain it.
Brian and Eran, thanks! Here are some discussion points:
--Dependency on web browsers:
OAuth rationale is to be an open protocol to allow secure API authentication in a simple and standard method from desktop and web applications, but still the spec requires the User to have a browser (section 6.2.1).
It follows that unless I implement certain aspects of HTTP in my desktop app (like redirects), it cannot participate in OAuth?
--Complexity
An initial read of OAuth hit my by a surprise how complex the protocol seems to be.
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.
Some discussion as to why these token exchanges are needed would make the spec much easier to understand.
The Service Provider is always the ultimate holder of the Protected Resource, so sharing of token between consumers/providers seems not to be a requirement for the token exchanges?
--Missed functionality
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?
--Relation to other methodologies
I know OAuth seeks to unify existing BBAuth/AuthSub/OpenAuth/Flickr Auth/etc. protocols, and that is a good idea.
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.
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?
At any rate, a discussion around deltas and differences from existing technology and OAuth would be useful.
And don't forget as I said before, I'd be willing to start and summarize (wiki page, perhaps?) this kind of Q/A to help future newcomers like myself get up to speed on the spec.
On Mon, Apr 7, 2008 at 11:18 AM, Brian Eaton <bea...@google.com> wrote:
> On Mon, Apr 7, 2008 at 8:54 AM, Hans Granqvist <hgranqv...@gmail.com> wrote: > > Hi everyone. I'm trying to find out about the rationale behind > > some of the OAuth design decisions.
> > The spec doesn't discuss this, and I can't seem to find anything > > on this mailing list (beyond some initial discussions that a rationale > > indeed is needed from beginning of August 2007), or on the web. > > Did I miss it?
> I started off in more or less the same boat as you, looking at a > specification that had almost no explanation of why things were done a > certain way. It's frustrating, it has led to implementation bugs, and > I hope future oauth extensions don't do silly things like tell you to > read the appendix just to understand what the spec is trying to > accomplish. There is no law that says specifications must be opaque.
> Ranting aside, though, I agree with Eran's recommendation: just ask. > Almost all of the specification has some reasonable rationale behind > it, and there are lots of people on this mailing list who can explain > it.
On Mon, Apr 7, 2008 at 12:29 PM, Hans Granqvist <h...@granqvist.com> wrote: > OAuth rationale is to be an open protocol to allow secure API > authentication in a simple and standard method from desktop and web > applications, but still the spec requires the User to have a browser > (section 6.2.1).
The service provider needs to know that the user authorizes the consumer to have access to their data. The only way to do that is for the user and the service provider to establish some line of communication outside of the consumer application. No comment on whether there are ways to do that besides a web browser, I haven't thought much about desktop deployments of OAuth.
> 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.
> 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
> I know OAuth seeks to unify existing BBAuth/AuthSub/OpenAuth/Flickr Auth/etc. > protocols, and that is a good idea.
AFAICT OAuth has nothing in common with OpenAuth, they solve totally different problems. OpenAuth tells you who a user is, but it doesn't give you permission to access a user's data. OAuth does just the opposite: the consumer can access the user's data without even needing to know their identity on the service provider site. (Note that I haven't actually tried to use OpenAuth, I've just read a few web pages. I might be wrong on what it can and cannot do.)
> 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.
No comment on "network-based capabilities", I'm not sure what you mean.
> 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?
On Apr 7, 12:29 pm, "Hans Granqvist" <h...@granqvist.com> wrote:
> --Dependency on web browsers:
> OAuth rationale is to be an open protocol to allow secure API
> authentication in a simple and standard method from desktop and web
> applications, but still the spec requires the User to have a browser
> (section 6.2.1).
> It follows that unless I implement certain aspects of HTTP in my
> desktop app (like redirects), it cannot participate in OAuth?
Redirects in your desktop application are not required. The desktop
flow allows the service provider (the website) to indicate that a
desktop application has been authorized in place of using a callback.
See the iMovie -> YouTube flow for inspiration. I believe this has
been captured via screenshots in Chris Messina's Flickr stream.
On Apr 7, 3:31 pm, "Brian Eaton" <bea...@google.com> wrote:
> On Mon, Apr 7, 2008 at 12:29 PM, Hans Granqvist <h...@granqvist.com> wrote:
> > OAuth rationale is to be an open protocol to allow secure API
> > authentication in a simple and standard method from desktop and web
> > applications, but still the spec requires the User to have a browser
> > (section 6.2.1).
> The service provider needs to know that the user authorizes the
> consumer to have access to their data. The only way to do that is for
> the user and the service provider to establish some line of
> communication outside of the consumer application. No comment on
> whether there are ways to do that besides a web browser, I haven't
> thought much about desktop deployments of OAuth.
Our solution is a limited secondary auth mechanism for partners we
'trust', who send us a raw (encrypted) username and password, and get
the oauth_token for the user right back - no web auth (for devices,
etc, which cannot web auth). For applications which do have access to
a browser, even if its a desktop app, the last 'callback' is
definitely optional, and it is possible to code in detection of
reaching that page so the flow is transparent.
That being said, there is some concern about having the consumer key/
secret embedded in a desktop app - I'm working on a way to make a
consistent 'variable/encrypted' consumer key solution that could help
work around this.
> > 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've not found one of the steps that is 'good' to shortcut. The fact
that the web auth process uses a separate one-time-use key is
important to keep the user token secure - its all about revealing as
little to the end user as possible.
> > 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
A solution we have for 'local' apps for users we already know are
logged in, etc, we just generate a 'authorized' request token, so the
app can exchange it for the full oauth_token for the user. Also, for
'anonymous' (non user) requests, we use the no-oauth_token method
(like the web auth token request piece) to verify just the consumer.
> > 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.
> No comment on "network-based capabilities", I'm not sure what you mean.
OAuth is also geared specifically for the web or at least http. It
can be readily implemented with two pieces of functionality which is
either built into implementor languages or can easily be built -
urlencoding and HMAC hashing.
> > 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?
A protocol for requesting and specifying resource rights I think is a
nice addition on top of OAuth, but I think the current implementation
is a quite nice, clean general specification which can be added on
to.
> > > 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?
> A protocol for requesting and specifying resource rights I think is a > nice addition on top of OAuth, but I think the current implementation > is a quite nice, clean general specification which can be added on > to.
I've been thinking about this for a while and have some ideas for the extension, based on previous proposals by others. If anyone else wants to participate please contact me and let's collaborate on the oauth-extension mailing list.
> > 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
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?
The Request Token is issued before the SP knows who the user is. Many
SPs may want to bake the userid into the AccessToken after the user
authorizes the consumer.
Also, the Request Token is intended short and easy to type, in order
to support the authorization of devices without web browsers. For
instance, if a user a trying to authorize a Chumby, the Chumby would
display the Request Token to the user to manually enter into a web
browser to continue the authorization process. Because the Request
Token needs to be easy to type, it needs to be short and probably
would have a limited character set. These properties make the Request
Token less secure than the Access Token.
Probably the OAuth community should emphasize more strongly that one
of the design goals was to forbid consumers from directly handling the
username/password.
Allen
On Apr 9, 10:26 am, "Hans Granqvist" <h...@granqvist.com> wrote:
> 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.
