Authorization vs. Authentication (was Re: Accountability in AC4CSR)

Ian Hickson wrote:
> On Wed, 13 Feb 2008, John Panzer wrote:
>   
>> 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.
>>     
>
> Agreed.
>
>
>   
>> 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.
>>     
>
> Also agreed. That's one of the reasons that XMLHttpRequest + Access 
> Control together let you set arbitrary extension headers.
>
>
>   
>> 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.
>>     
>
> Right, you'd have to use X-OAuth or something like that. "Authorization" 
> headers are reserved for user and client authentication [sic], as 
> described in HTTP 1.1 section 14.8.
>
>   
Relevant text, just for reference:


      14.8 Authorization

      A user agent that wishes to authenticate itself with a server--
      usually, but not necessarily, after receiving a 401 response--does
      so by including an Authorization request-header field with the
      request.  The Authorization field value consists of credentials
      containing the authentication information of the user agent for
      the realm of the resource being requested.

          Authorization  = "Authorization" ":" credential

>   
>> 1. Should OAuth invent a new header for authorization?  That is, should 
>> we not be using Authorization: for authorization?
>>     
>
> When it's direct A-B communication, and A is authenticating to B, then 
> Authorization: is appropriate. When there are three parties, and the 
> communication is from C to B on behalf of A, the Authorization: header is 
> authenticating C, not A. A needs to use different headers in this case.
>   
I'm not sure I understand the distinction being made here, possibly 
because OAuth doesn't really follow this model?  Let me try to work this 
out...

Take the delegated server case first.  I, the user, talk to server B and 
tell it that it's okay for server C to do certain operations on my 
behalf (read my address book for example).  I believe I'm A in this 
case.  So later on, C can talk to B on my (A's) behalf in order to 
retrieve my address book data.  In the case of OAuth, there are actually 
two components to this:

1. C proves that it's C to B (typically by signing with a long-lived 
shared secret)
2. C asserts that it has permission from A to do the operation (by 
signing with a second, shorter lived shared secret generated when A 
granted permission)

However, (1) and (2) aren't physically separated -- the secrets are 
combined and both are used to sign the request.  There is no separate 
authentication/authorization step, just a single auth[nz] step.  So it 
appears that we're authenticating C in this case (and also authorizing 
the specific request).

Now in the case of CSR, I'll assert that C is a distributed system 
consisting of a server component plus Javascript extensions that run on 
my desktop in a sandbox.  From my P.O.V. as a user, I'm still dealing 
with C.  I talk to B and tell it it's okay for C to read my address 
book; C's Javascript then executes (1) and (2) and makes the CSR call to 
B.  Is the situation different than in the delegated server case?

Aside #1: The security is definitely different if we leak secrets to end 
user machines, but there are ways to deal with that that don't affect 
this discussion I think.

Aside #2: To make things more complicated, in some cases you can skip 
(2); for operations that don't require user permissions, for example, or 
where the user permissions are asserted some other way.  In this case 
you have the same mechanism but simply use an empty string for step 2, 
so effectively you are only proving that you're C.

Aside #3: To make things even more complicated, OAuth also allows for 
semi-trusted assertions for #1, for example if you have a desktop 
application where the 'secret' ends up stored on an end user's 
computer.  You have to assume that this secret can be found and copied.  
This is also similar to the case where you download Javascript to an end 
user's computer and perform signing there, so it's probably the relevant 
case for CSR.  However, it would be possible to generate a unique secret 
per end user computer too, so you can still do both #1 and #2 together 
even with CSR.

Aside #4:  Both Google AuthSub and Amazon's auth use Authorization: for 
this purpose :).

-John