On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott <andrewarn...@gmail.com> wrote: > Ah, got it. Yes, we're on the same page. > I happen to store the authorization tuple (mentioned in another thread) > rather than the refresh token itself. That way I can issue an arbitrary > number of refresh tokens for the same client/user/scope/issued_date set > without storing any extra data in the database, but I can still support > revocations by deleting the standing authorization from the db. Obviously, > each time a refresh token is received, its corresponding tuple in the table > is checked to be present to detect revocations.
That's a reasonable design trade-off... One possible issue there is compromise of the token database. If a token database leaks for any reason, all of the refresh tokens would have to be revoked. If you stored a one-way hash of the tokens instead, compromise of the token database would be less dangerous. (Note that this depends how the database was compromised, of course...) _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
