On Tue, Jul 13, 2010 at 1:56 PM, Brian Eaton <bea...@google.com> wrote:
> 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...) > I'm not storing tokens at all. And a compromise of the database wouldn't expose any tokens or their hashes. I'm only storing that user/client/scope/issued_date tuple -- not the token itself.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
