On Mar 9, 2010, at 8:16 PM, David Recordon 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).
To throw another opinion on the fire - access tokens shouldn't be required to be over an order of magnitude smaller than browser cookies or HTTP headers, and nearly an order of magnitude smaller than a URL. In fact, 256 characters is only barely long enough to hold the longest allowed domain name. To parallel browser cookies, HTTP headers and URLs, there are accepted 'minimum maximums' out there - which the minimum size that user agents are expected to support, and the maximum size the server will assume be supported by an arbitrary agent. I don't believe all of these are formalized, but they all exist. > 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. Sounds like they should consider picking a different database vendor. -DW _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
