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
