Re: [OAUTH-WG] RSA signing and web delegation

[Brian Eaton <beaton at google.com>]

On Thu, Nov 5, 2009 at 8:15 PM, Manger, James H
<James.H.Manger at team.telstra.com> wrote:
>> 1) Initial requests for user approval .. are signed using RSA.
>> 2) Data requests .. are signed only with the token secret using HMAC.
>> 3) Requests to renew access tokens (if we adopt something like the
>>     scalable OAuth extension) are again signed using RSA.
>
> Why do you need to use the RSA key during token renewal?

Requiring the consumer secret (whether is an HMAC secret or an RSA
private key) during renewal helps you recover from compromise.

For example, consider this scenario:
1) Client receives permission to access data on behalf of thousands of users.
2) Client gets hacked.  Attacker steals all of the delegation tokens.
3) How do you recover?

If access token renewal does not require the consumer secret, you're
screwed.  You have to revoke all of the delegation tokens for all of
the users, and they need to reapprove.

If access token renewal *does* require the consumer secret, recovery
is much simpler.  You rotate the consumer secret, and the attacker
loses access to user data.


> If renewal can be occur at any time at the discretion of the server, then the client will always need
> the RSA key handy. It sounds like it will be hard for a client to get any benefit from not needing
> the RSA key for resource requests if, at any moment, it needs the RSA key to renew the token
> to complete a resource request. It seems to make it tough to hand a user-specific token to
> javascript running in that user's browser, for instance.

This is a good point.  Well behaved service providers should have
predictable and usable session lifetimes.  For example, the client web
site can get a session token that is good for one hour, and hand it to
some javascript to use for one hour.  At the end of that hour, the
client web site needs to refresh the token.

> It should be sufficient for the security server to be able to distinguish the original
> client that a token was returned to, from a malicious party that learnt the token
> details from a compromised content server. Two quick ideas:
>
> 1. A cookie set by the security server when issuing the token would be
> sufficient. The client would return the cookie during renewal; the compromised
> content server never sees this cookie.

IMHO, web APIs should not use cookies.  (This is mostly a matter of
opinion on my part, based on problems I've had with distributed cookie
jar management and general annoyance in the past.  I suspect if you
ask application developers they'll tell you the same thing).

> 2. A better alternative might be for the security server to provide a renewal
> URL when issuing a token. The renewal URL can be unique to the token.
> A compromised content server never sees the renewal URL so it cannot renew a token.

I like this idea, particularly if renewal requires both the renewal
secret and the consumer secret.

The consumer secret is useful because of the issues I mentioned above
with recovering from compromise.

The renewal secret is useful because it acts as a long-lived
capability to access user data.  This is particularly important for
installed applications, where the consumer secret isn't really a
secret.

Cheers,
Brian