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 protected]> wrote: > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
