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" <rbar...@bbn.com> 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
