[cap-talk] Why tokens have short lifetimes in OAuth-WRAP

David Barbour dmbarbour at gmail.com
Thu Mar 18 01:42:19 PDT 2010


Assume three distributed agents:

* Alice, the Administrator, provides access-tokens to resources on
Sally and other servers to authorized users.
* Sally, the Server, has a bunch of resources to share.
* Carl, the Client, is authorized access to a resource.

The basic access pattern: Carl proves authority to Alice and obtains
an token T from Alice to access resource R from Sally. Carl then
presents T to Sally to ask for the resource R. At this point, Sally
must determine whether T is a legal token for R. If it is, then Sally
provides Carl the designated access to the resource.

The goals: avoid proxy and support revocation. Alice doesn't have a
big enough data-pipe to handle Carl and all his friends.

The question: How does Sally prove T is a valid token for R?

Answer A: T is volatile and has a built-in expiration - i.e. perhaps
30 minutes - along with an authentication code that Sally is willing
to recognize. Carl, the client, will essentially obtain a stream of
fresh tokens T1, T2, ... Tk until he no longer demands access to the
resource. Alice can revoke access by cutting off that stream at any
time. Sally does not need to communicate directly with Alice.

Answer B: T is long-lived; Alice may revoke T explicitly. When Sally
receives T from Carl, she must call back to ask Alice whether T has
been revoked. Carl will continue to use T over time. Sally and Alice
will need to continue to communicate, intermittently, to see whether T
is later revoked. I.e. Alice might suggest that each test by Sally
have a 30 minute timeout.

Importantly, consider 'heavily shared' resources - i.e. assume Carl
has a hundred pals who all want to share access to a resource on
Sally.

The long-lived token approach will require that Sally make 101 calls
back to Alice, for 101 different long-lived tokens for the resource.
Different tokens are necessary because Alice is revoking them
independently. Sally will then need to keep a memory of 101 tokens,
and will need to re-negotiate access to resource R for each of those
101 tokens with Alice when they near the 'revocation' time-out period.
If the revocation test rate is 30 minutes, that means an average of
one such negotiation every 18 seconds, for just the one resource! Now,
Alice could optimize a lot by maintaining a heartbeat with Sally and
revoking tokens to Sally more explicitly, but that still doesn't avoid
the initial 101 calls to Alice, nor of the memory. Thus, as I noted
earlier, the "constantly checking with the central backend" can
quickly become a scaling problem as the number of clients increase.

The volatile token approach is cleaner on Sally's side, since Sally
doesn't need to keep any memory of the tokens. Each token can simply
be validated against its expiration and auth code, which can be done
locally.

OTOH, you're largely just shifting communication burdens around. The
short-lived tokens force Alice to communicate more often with Carl.
(Though, this shifting might prove useful for other reasons, such as
firewalls issues and such.)


More information about the cap-talk mailing list