Hi David,
let me first explain my thoughts in general before I fill in my replies
to your questions.
In my opinion, all four combinations of transport and signature are
valid and can be used in different scenarios:
-bearer token/http - comparable to session cockies over http (possibly
very short token lifetime or/and token is a random number)
-signature/http - already discussed
-bearer token/https - already discussed
-signature/https - signature additionaly provides a) end-2-end
message-level security b) holder of key verification
Thus I would not assume a dependency between token secret and http(s)
communication.
From my point of view, a service should define which combinations it
supports/requires and announce this as part of the client discovery
process (e.g. as properties of the WWW-Authenticate response). A client
then requests a suitable access token w/ or w/o secrets from the
authorization server. Services definitely need to know the corresponding
secret in order to verify signatures. But there are different strategies
I can imagine how it gets access to the secrets (e.g. shared database,
add encrypted secret to token like Kerberos, push secrets to target
services). Therefore I would suggest to left this point open to OAuth
implementations.
I would suggest only to issue shared secrets because I don't see any
need for public-key crypto here.
Has anyone else put some thought into what secrets are used within the
signature algorithm for OAuth 2.0?
OAuth 1.0 combines the client secret and the token secret with an
ampersand in the middle. WRAP doesn't support signatures and relies
on the fact that access tokens should remain secret via SSL or are
extremely short lived and thus lower risk.
Here are the options as far as I'm aware (without making changes to
WRAP's assumptions):
1) Sign using the client secret. Doesn't work because the access
token would be sent over the wire in plaintext and some servers will
make them long lived in 2.0.
Usage of client secrets to sign resource requests is one of the major
issues in OAuth 1.0a from operation security and performance
perspective. So I would discourage from this option.
2) Issue an access token secret if an optional parameter is specified
by the client during the authorization profile request(s). Doesn't
work for the same reason as #1 assuming that the same access token can
be used via SSL.
I would vote for this option. Can you please clarify why you think this
option won't work?
3) Instead of adding an optional parameter to each authorization
profile, have the client immediately refresh the access token and
support an optional parameter to request an access token secret. This
lessons the impact of supporting signatures on most implementors when
reading the spec and given that most signature use cases have longer
lived tokens, the overhead of the extra HTTP request should be
infrequent compared to the number of protected resource requests
you'll make with it. Doesn't work for the same reason as #1 assuming
that the same access token can be used via SSL.
Why do you expect signature based use cases to have long-living tokens?
While I'm not a crypto expert, it seems impossible to treat the same
access token as potentially public when using signatures but secret
when using SSL. I believe that authorization servers will need to
keep track of the access tokens that the client has requested a secret
for and from that point on only allow the use of that particular
access token 1) via signatures or 2) via SSL when the access token
secret is passed in as well.
I don't think an authorization server can (and should) enforce usage of
access token secrets. It should just issue such secrets and ensure
services get to know it. Whether the secret is required is a decision of
the target service. To exaggerate a bit: a client could even request an
access token w/ secret and just throw the secret away if the target
service does not require signed requests.
regards,
Torsten.
Thoughts?
Thanks,
--David
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
