Actually, Brian and I discussed this very topic at some length after
the OAuth after-party today. If you think about it, it is impossible
to completely separate the Authz Server (AS) from the Protected
Resource (PR) -- in all of the possible cases, the AS needs to be able
to pass secure messages to the PR, in one form or another.
In the signing cases, this is obvious: The AS needs to provide the PR
with a key to validate signatures (either a MAC key or a public key).
However, it remains true even for bearer tokens, since the AS needs to
communicate to the PR which tokens are valid tokens. This
communication needs to be secure, so that tokens can't be spoofed.
In either case (signing or bearer), secured validation information has
to get passed from the AS to the PR. Based on the phrase "validate
Access Tokens", it sounds like you're already acknowledging that the
token can have internal structure that constitutes a secure message
from the AS (e.g., if token == request-uri + signature). But even
that assumes that the AS and the PR share a key pair (symmetric or
asymmetric).
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
On Mar 22, 2010, at 4:20 PM, Allen Tom wrote:
Hi All -
Regarding the client secret - one of the design goals for OAuth-WRAP
was to
cleanly separate the AuthZ server from the Protected Resource. The
Protected
Resource should only have to know how to validate Access Tokens
issued by
its AuthZ server.
The HMAC-SHA1 signature method defined in 4.2.1.1 of the Oauth 2.0
spec
violates this principle because it requires the protected resource
to have
the client secret in order to validate the signature. Distributing the
client secret to all Protected Resources can have negative security
and
performance implications.
http://www.ietf.org/mail-archive/web/oauth/current/msg01396.html#compute_sig
I recommend removing the client secret from the signature
calculation, and
instead using only the Access Token secret.
Allen
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
