On Tue, Mar 9, 2010 at 7:16 PM, David Recordon <record...@gmail.com> wrote: > The challenge is that client developers (who we really want to make > OAuth dead simple for) will be forced to use less optimal storage for > tokens (blobs versus shorter and indexable types such as varchars). > They also won't be able to build any assumptions around token length > into their database design. Any DBA cringes when they see the blob > type for multiple columns within a table (access token and refresh > token per user).
Why would you index the refresh token column? I think it is enough to lookup by user id and just retrieve the token. Also, quite likely that you don't need to store the access token in the SQL database at all and just make it a session attribute. Not sure what is reasonable for session data, a large set slows down replication, but a typical access token should be OK I think. > Some OAuth servers will have short tokens which a client might > integrate with first and decide that a varchar(255) is reasonable to > hold tokens. They'll then run across a server with longer tokens, not > realize it, and be confused why their client isn't working when it's > due to their database silently truncating tokens after 255 characters. Well, silently truncating data is a different issue altogether. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
