I'd still like to see someone construct an example access token that is longer than 255 characters that would be reasonably used. If there are real, legitimate use cases that REQUIRE more than that many characters, then let's hear them. I don't think that appealing to "it might be useful" is a good enough argument.
> nearly an order of magnitude smaller than a URL I'd hope so, given that it is supposed to be a single URL parameter, and it has to share that URL length with other parameters to actual API calls. > I don't believe all of these are formalized, but they all exist. The lack of formalized URL length limits has been a headache for us, since we end up testing each browser and coding to the most restrictive. I'd like to avoid the need for OAuth clients to do the same. On Mar 9, 2010, at 10:33 PM, David Waite wrote: > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
