Ian Hickson wrote:
On Wed, 13 Feb 2008, John Panzer wrote:
party A: original server
party B: third-party server, service provider
party U: user, client, user agent, browser
U visits A, which returns a page that then attempts to communicate with B.
On Wed, 13 Feb 2008, John Panzer wrote:
What mechanism do you propose clients and servers implement use to
authenticate users for CSR requests?
HTTP Authentication and/or cookies, like they do now. If the user
isn't logged in, the third-party server would return an error to the
client, and the page from the original server would then redirect the
user to the third-party server (the service provider) to get them to
log in.
Except that's not what they do now. If you look at the Flickr auth API
for example:
http://www.flickr.com/services/api/auth.spec.html
you'll see that it does use redirects and cookies to establish a user
session at their site. But for the actual API calls, it relies on
signed JSONP cross-domain requests, not cookies, to mitigate request
forgery.
You asked how the user was authenticated, and that is, even in this
example, via the server itself handing out credentials to the user (in
the form of a cookie).
Now, the question of how the original server obtains authorisation from
the service provider is a different one. However, again, the mechanism
described above and used today would still work with Access-Control.
Well, actually it won't, it will just force those security mechanisms to
continue to be stuffed into the URL parameters and/or custom headers.
This has impacts on libraries, proxies, and cacheability.
Could you give a concrete example of a case that is negatively impacted
here? As far as I can tell, the impact to which you refer is exactly what
we want.
Because servers have to implement _something_. Realistic mechanisms
have to be resistant to distributed brute force attacks even without
AC4CSR (thank you, Storm Worm). On a side note, I hope that servers
opting in to CSR would never consider using username/password auth
on each request. Since it is possible to implement username/password
auth in ways opaque to browsers ("&u=foo&pass=bar"), perhaps this is
worth a note in the security section.
The original server shouldn't ever have access to the _user's_
credentials, certainly.
Yes, it should. If the user has had a conversation with party B and
elected to share credentials with party A, which is what happens with
Flickr auth today. (Note that 'credentials' in this case are going to
be an opaque and likely limited access token, _NOT_ a password of any
kind.)
What the service provider gives the original server in the Flickr case is
not the user's credentials (or indeed any kind of authentication), but an
authorization token to confirm that the user has permitted the site to do
what it wants to do.
Above, I got a bit tangled up (originally I was making a point about
re-use of existing APIs that might naively accept usernames and
passwords, misinterpreted Ian's response, and started talking about
authorization tokens.) Sorry, let me start over.
I'm really concerned with authorization, not authentication. An API
needs to do an authorization check on a CSR request, not an
authentication check. For CSR especially, just doing an authn check
doesn't give you valid evidence of authorization.
Some of today's APIs like Flickr put authorization evidence into URL
query parameters for CSR. It's mildly bad to do this because such
things are more likely to get logged and sniffed than headers, and you
can't separate the resource URL from the authorization proof being
presented to use it, which would be useful in caching.
The OAuth spec uses
Authorization: OAuth ...
by preference for these reasons, where the ... represents an
authorization proof provided by the party A script. It looks like this
is disallowed by the AC4CSR specification. It says that "authentication
credentials" should not be permitted to be set by [the party A script].
Since HTTP doesn't separate authorization and authentication, in
practice this seems to mean that Authorization: isn't settable. Per the
discussion above, we're really talking about authorization, not
authentication. So, some random thoughts...
1. Should OAuth invent a new header for authorization? That is, should
we not be using Authorization: for authorization?
2. Should the spec wording ban only authentication uses of the
Authorization header (that is, Basic/Digest) and allow authorization
uses of Authorization (e.g., OAuth)?
John
