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 <esjew...@gmail.com> 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 <dick.ha...@gmail.com> wrote: >> >> On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote: >> >>> On Tue, Mar 9, 2010 at 3:50 PM, David Recordon <record...@gmail.com> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > 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
