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" <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
