Subject: [OAUTH-WG] Invalidating access tokens

From: David Recordon <[email-masked]>
Date: Thu, 4 Mar 2010 10:55:24 -0800

Copying over a discussion from comments on my blog...
http://daveman692.livejournal.com/349384.html?thread=1117640#t1117640

Mart Atkins:
> Doing short-lived access tokens in cleartext is not really any different to how most sites
> handle sessions today. A short-lived access token isn't much different than a session key.
>
> However, if access tokens are going to be used in this way it's probably sensible to define
> a mechanism by which a consumer can explicitly invalidate an access token. This means
> that an access token can be tied to the live of a site session: when the user logs in (or,
> when they first do something that needs the access token) use the refresh token to obtain
> a new access token; when the user logs out, terminate all of the active access tokens
> associated with that session.

David Recordon:
> An invalidate method makes sense, though wouldn't this just happen by refreshing the
> token anyway? You'd get a new access token and the old one would stop working.

Mart Atkins:
> Maybe that would work, as long as the new access token is known only to the consumer
> until the next time the user logs in. Obviously the difference with explicit invalidation is
> that when the user isn't around there are no valid access tokens at all for that user.

---

From: Brian Eaton <[email-masked]>
Date: Thu, 4 Mar 2010 14:33:25 -0800

>> handle sessions today. A short-lived access token isn't much different than a session key.

Yep.  This is not an accident, and the pattern extends way beyond the
web.  You see it in pretty much every trusted third-party
authentication system.

>> associated with that session.

I'm sure an invalidate method would be useful for refresh tokens,
though not essential.

I suspect most WRAP deployments won't be able to do server-side
invalidation of access tokens; they'll be implemented without
server-side state.  It does turn out that the WRAP refresh
token/access token pattern does make server-side invalidation fairly
efficient to implement if deployments decide to care.

>> token anyway? You'd get a new access token and the old one would stop working.

I don't think this is a good idea.  There's no guarantee that the old
access tokens are not still being used at the time that the new access
token is minted.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Mar 2010 17:06:27 -0700

I don't buy the argument that future security should be modelled after  
the broken security we have today.

EHL

On Mar 4, 2010, at 10:55, "David Recordon" <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth