Re: [OAUTH-WG] OAuth 2.0: client_secret, state

[Richard Barnes <[e-mail]>]

Allen,

Right, the PR needs to have the client's access token so that it knows  
which access tokens to accept.  The AS issues the access token, so in  
order for the PR to know the access token, the AS need to send a  
secure message to the PR saying that "this access token is OK".  This  
communication can happen either directly or indirectly:
-- Direct: AS tells PR which access tokens are valid
-- Indirect: AS signs access token

Either way, the PR has to be able to authenticate messages from the  
AS, so it has to have a public key or shared key for the AS.  That  
same key could be used to communicate keys to validate signatures from  
clients (access token secrets).

So disallowing signatures actually doesn't save you anything in terms  
of the crypto that the PR and AS need.

--Richard



On Mar 23, 2010, at 11:42 AM, Allen Tom wrote:

> Hi Richard,
>
> From a security perspective, it might be undesirable to distribute the
> client secret to all potential protected resources that a client  
> might want
> to access.
>
> In many ways, distributing the client secret to all PRs is  
> undesirable in
> the same way that it's undesirable to distribute the user's password  
> to all
> PRs. Even if the client secret is encrypted into the Access Token,  
> it has to
> be extracted by the PR to verify the signature (at least using the  
> current
> version of the Oauth 2.0 spec).
>
> If the client secret is distributed to the PR, the PR would be able to
> impersonate the client. (Unlike Oauth 1.0, the PR and the AuthZ  
> server are
> separate entities)
>
> Admittedly, with Oauth-WRAP, the PR would still have a client's access
> token, however, the access token could be scoped to be only valid  
> for the
> PR, so a PR might not be able to impersonate the client by replaying  
> the
> access token, and also the Access Token has a limited lifetime.
>
> Hope that helps to clarify things,
> Allen
>
>
> On 3/22/10 10:19 PM, "Richard Barnes" <[e-mail]> wrote:
>
>
>>
>> If you make the same two assumptions -- shared keys and structured
>> tokens -- then the signing cases can also work via the token: You can
>> just encrypt the validation key (MAC key or public key) with the
>> shared key and put it in the token.
>>
>> So from the perspective of the need for a relationship between AS and
>> PR, there is absolutely no difference between the "bearer token" and
>> "signing" use cases.
>>
>> --Richard
>>
>