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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
