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

[David Barbour]

On Sat, Mar 20, 2010 at 8:42 PM, David-Sarah Hopwood
<david-sarah at jacaranda.org> wrote:
> The server can temporarily cache the results of a revocation check.

True. But I had already assumed this.

>
> Notice that the server must perform at least as many revocation checks
> in the first approach (using short-term tokens) as in the second (using
> long-term tokens).

This is not the case.

For volatile tokens, there is no need for explicit revocation, there
is no need for the initial access check, there is no need for 'memory'
of which tokens have been created. Instead, the payment is on the
'refresh' side.

I'd like to note that I'm not endorsing either approach. I suspect
which costs more will depend upon exactly how the access tokens are
used for a given service. For example, whether refreshes are actually
needed will depend heavily upon which service is being provided (i.e.
a continuous service vs. a one-time deal).

I'd also guess that OAuth is having to make some difficult trade-offs
to maintain compatibility with HTTP and HTTPS, deal with service
mirroring and databases, etc. As Kenton noted, avoiding the need for
state or a database to check whether a token is still valid is not an
insignificant benefit once you start dealing with mirrored or
distributed servers.