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

[Allen Tom <[e-mail]>]

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
>