On Thu, Mar 4, 2010 at 10:55 AM, David Recordon <record...@gmail.com> wrote: > 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.
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. >> 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. 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. >> 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. 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
