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 On Tue, Mar 9, 2010 at 7:16 PM, David Recordon <[email protected]> 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). > > 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. > > --David > > On Tue, Mar 9, 2010 at 6:24 PM, Ethan Jewett <[email protected]> wrote: > > Agreed. I've heard tell of Yahoo access tokens with encoded > > information weighing in at up to 800 characters. I don't see anything > > necessarily wrong with this and I don't think there's much reason to > > limit it in the spec. It could incur a significant bandwidth cost, but > > since the provider is going to shoulder most of this cost the provider > > in a good position to make the tradeoff calculation. > > > > I think it would make sense to advise client library and application > > programmers to provide for the possibility of and storage of large > > tokens. We should probably reference examples of tokens seen in the > > wild and mention the technical limitations on token length from the > > HTTP protocol (with Dick outlines). I'm not sure where in the spec > > this would go, but it sounds like a good thing to include. > > > > Ethan > > > > On Tue, Mar 9, 2010 at 8:14 PM, Dick Hardt <[email protected]> wrote: > >> > >> On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote: > >> > >>> On Tue, Mar 9, 2010 at 3:50 PM, David Recordon <[email protected]> > wrote: > >>>> Ideally we'd limit the length of access and refresh tokens as well as > >>>> client keys and secrets to no more than 255 characters (a one byte > >>>> varchar in MySQL). > >>> > >>>> Is this an issue for anyone? > >>> > >>> That being said, I don't see a problem with limiting the lengths. > >> > >> I would not want to limit them anymore than they need to be. > >> When editing OAuth WRAP, we looked into size issues. Current limits are > HTTP header size limitations, which are 4-8K total. > >> > >> Given the ability to put all the claims needed into the Access Token, I > can see Access Tokens being 1-2K and being really useful. > >> > >> -- Dick > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
