Re: [OAUTH-WG] Defining a maximum token length?

[David Recordon <[e-mail]>]

On Tue, Mar 9, 2010 at 7:25 PM, Dick Hardt <[e-mail]> wrote:
> I understand the desire to set a max length that can easily fit into a DB.
> There are lots of other items I think the developer is storing that can be
> long as well, like URLs -- so I don't see it as a huge issue.
> I do see the need to make it clear that it can be a few K or something like
> that so that people don't assume it is shorter than it might be.
> -- Dick

Why would the URLs be stored in a database?  Wouldn't they be in
configuration files given that OAuth doesn't support discovery of new
servers?  Yes, developers do store URLs in databases but it's
generally not very optimized.


On Tue, Mar 9, 2010 at 7:25 PM, Marius Scurtescu <[e-mail]> wrote:
> On Tue, Mar 9, 2010 at 7:16 PM, David Recordon <[e-mail]> 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.

Agreed, you shouldn't need to assuming that you only have one access
token per server/user combination.  Ignoring indicies, in MySQL a
varchar up to 255 characters takes one byte whereas a blob (or a
varchar over 255 characters) is the number of bytes for the string
plus two extra bytes.

In MySQL allowing tokens over 255 characters triples your storage
requirement in the best case. We're not talking about a lot of data
here, but it is worth noting that this design decision has a direct
impact on implementors.


> 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.

That's true if all access tokens expire frequently.  We plan to also
offer long lived access tokens.


>> 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.

Sure, but standards can't just work in theory. :)


> Marius
>