Re: Accountability in AC4CSR

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 13 February 2008 22:04:18 UTC