On Tue, Jul 13, 2010 at 1:37 PM, Brian Eaton <[email protected]> wrote:
> On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott <[email protected]> > wrote: > >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy, > >> these pretty much have to be backed by server-side state or there is > >> no way to run your system. > > > > Brian, can you tell me what you mean by cryptographically implemented > > refresh token, and why using one would be crazy? You say using them > would > > require server-side state. I'd say just the opposite. If you > are signing > > your refresh tokens (a cryptographic operation) you don't need to store > them > > on the auth server, but if you aren't using cryptography, then you must > > store the tokens on the auth server in order to validate them when they > come > > back to you. > > So in short, I'm thinking the opposite of what you state. So please > > enlighten me. What am I missing? > > You and I are on the same page. Let me try again. > > Anyone implementing OAuth 2 needs to store information about issued > refresh tokens server-side, otherwise basic functionality such as > revocation is not possible. > > Cryptographically implemented refresh tokens, without that > corresponding server-side state, are crazy. > 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.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
