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

From: Luke Shepard <[email-masked]>
Date: Fri, 9 Apr 2010 03:14:15 -0700

Let's finish off the thread on token length limits.

In summary, David Recordon proposed a length limit of 255 characters due to database length limits ("blobs versus shorter and indexable types such as varchars"). Several people were opposed to the 255 length limit. However, there was general favor of a limit, but just it should be a bit longer.

So, what is a reasonable limit for the token length?  1k? 2k? 4k? 5mb? I suggest some language like this:

	Access tokens MUST be less than 2KB.

Here are some representative comments from the thread:

David Recordon: 
	"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)."

Chuck Mortimore: 
	"Standards have size limits to overcome operational issues all the time."

Dick Hardt: 
	"I would not want to limit them anymore than they need to be... I do see the need to make it clear that it can be a few K or something"

Ethan Jewett: 
	"I've heard tell of Yahoo access tokens with encoded information weighing in at up to 800 characters."

Torsten Lodderstedt: 
	"For our token format, access token length would vary between 200 and 700 Bytes."

David Waite: 
	"access tokens shouldn't be required to be over an order of magnitude smaller than browser cookies or HTTP headers... 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."

John Kemp: 
	"Why would we want to encode such a specific implementation decision into the OAuth standard?"

And there were some cited precedents for length limits in standards:

- SAML (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)
  "Persistent name identifier values MUST NOT exceed a length of 256 characters."

- Email
   http://www.faqs.org/rfcs/rfc2822.html)
   There are two limits that this standard places on the number of
   characters in a line. Each line of characters MUST be no more than 
   998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.

   http://www.ietf.org/rfc/rfc2821.txt
   There are several objects that have required minimum/maximum sizes.
   Every implementation MUST be able to receive objects of at least
   these sizes.  Objects larger than these sizes SHOULD be avoided when
   possible.  However, some Internet mail constructs such as encoded
   X.400 addresses [16] will often require larger objects: clients MAY
   attempt to transmit these, but MUST be prepared for a server to
   reject them if they cannot be handled by it.  To the maximum extent
   possible, implementation techniques which impose no limits on the
   length of these objects should be used.

---

From: Brian Eaton <[email-masked]>
Date: Fri, 9 Apr 2010 12:12:16 -0700

>        Access tokens MUST be less than 2KB.
<snip>
>  "Persistent name identifier values MUST NOT exceed a length of 256 characters."

Note that access tokens are more like SAML assertions (which have no
size limits) than persistent name identifiers.  Persistent name
identifiers are basically user ids.

Anyone who is using access tokens in web delegation flows is going to
need to be careful of size limits.

But there are a bunch of use cases for access tokens outside of those flows.

So would it make sense to give size recommendations based on the
profile being used?

Cheers,
Brian

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 9 Apr 2010 21:01:39 +0000

I would actually like to see the inclusion of reference tokens here also, I do think that the 255 character limit is too restrictive and needs to be revisited.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Eaton
Sent: Friday, April 09, 2010 12:12 PM
To: Luke Shepard
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?

<snip>
> - SAML 
> (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)

Note that access tokens are more like SAML assertions (which have no size limits) than persistent name identifiers.  Persistent name identifiers are basically user ids.

Anyone who is using access tokens in web delegation flows is going to need to be careful of size limits.

So would it make sense to give size recommendations based on the profile being used?

Cheers,
Brian
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Allen Tom <[email-masked]>
Date: Fri, 09 Apr 2010 16:49:49 -0700

I think a good precedent would be to use the HTTP Cookie size limit, which
is 4KB.

An OAuth Access Token is like an HTTP Authorization cookie. They're both
bearer tokens that are used as a credentials for a client to access
protected resources on behalf of the end user.

All Oauth clients have to implement HTTP anyway, so 4KB sounds like a
reasonable limit.

Allen

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 22:16:00 -0700

I would argue that for the spec to provide a token size limit that is greater than 255 would cause more harm than good. This is not to say I am supporting the 255 limit (I take no position on the matter - yeah, that happens rarely). If the spec provided a 4K limit, client libraries are likely to codify that which will make them extremely wasteful for 99% of the popular cases on the web today. A 4K limit doesn't really improve interop since the limit is so high, no one is likely to issue even bigger tokens with public APIs.

The 255 limit keeps the token size within the most effective database field size limit for this type of identifier. If we cannot reach consensus on this size limit, I don't think the spec should say anything. However, if I wrote a client library, I would make it use a 255 default size limit and require a custom configuration to enable it to use something else.

So my proposal is 255 or no size guidance/restriction.

EHL

On 4/9/10 4:49 PM, "Allen Tom" <[email-masked]> wrote:

Allen

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Apr 2010 08:56:51 +0200

+1 no restriction, please

256 is much too short

Am 10.04.2010 07:16, schrieb Eran Hammer-Lahav:
> I would argue that for the spec to provide a token size limit that is 
> greater than 255 would cause more harm than good. This is not to say I 
> am supporting the 255 limit (I take no position on the matter -- yeah, 
> that happens rarely). If the spec provided a 4K limit, client 
> libraries are likely to codify that which will make them extremely 
> wasteful for 99% of the popular cases on the web today. A 4K limit 
> doesn't really improve interop since the limit is so high, no one is 
> likely to issue even bigger tokens with public APIs.
>
> The 255 limit keeps the token size within the most effective database 
> field size limit for this type of identifier. If we cannot reach 
> consensus on this size limit, I don't think the spec should say 
> anything. However, if I wrote a client library, I would make it use a 
> 255 default size limit and require a custom configuration to enable it 
> to use something else.
>
>     >> So, what is a reasonable limit for the token length?  1k? 2k?
>     4k? 5mb? I
>     >> suggest some language like this:
>     >>
>     >>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Apr 2010 09:05:49 +0200

Hi Allen,

as I already posted, I don't think a size limit is a good idea.

Regarding your example: As per RFC-2109, 4KB is the minimum size that 
must be supported by user agents. The maximum size is not restricted:
"In general, user agents' cookie support should have no fixed limits.".

Moreover, other HTTP authentication mechanisms need much more than 4KB, 
For example, SPNEGO authentication headers can be up to 12392 bytes.

regards,
Torsten.

Am 10.04.2010 01:49, schrieb Allen Tom:
>> On Fri, Apr 9, 2010 at 3:14 AM, Luke Shepard<[email-masked]>  wrote:
>>      
>

---

From: John Kemp <[email-masked]>
Date: Sat, 10 Apr 2010 09:37:03 -0400

> as I already posted, I don't think a size limit is a good idea.

+1 

> 
> Regarding your example: As per RFC-2109, 4KB is the minimum size that must be supported by user agents. The maximum size is not restricted:
> Moreover, other HTTP authentication mechanisms need much more than 4KB, For example, SPNEGO authentication headers can be up to 12392 bytes.

Cheers,

- johnk

---

From: Naitik Shah <[email-masked]>
Date: Sat, 10 Apr 2010 12:49:22 -0700

+1 small tokens.

JSON-P in IE to access protected resources has a limit of some 2000 bytes of
input. While the OAuth 1.0 did not have a practical client side profile, we
now do have one. This at least opens up the possibility of building browser
based OAuth applications that do not need to proxy API requests to jump the
cross domain boundary. To make this practically useful, the tokens would
need to be small leaving as many of the 2000 bytes as possible for the API
request itself.

-Naitik

On Sat, Apr 10, 2010 at 6:37 AM, John Kemp <[email-masked]> wrote:

> >>>> So, what is a reasonable limit for the token length?  1k? 2k? 4k? 5mb?
> I

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 12 Apr 2010 09:23:14 +0000

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Friday, April 09, 2010 11:57 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?

256 is much too short

EHL

Allen

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Apr 2010 13:39:27 +0200

Is there some other natural parameter limit in place from HTTP?

Eliot

On 4/12/10 11:23 AM, Anthony Nadalin wrote:
>
> +1
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Torsten Lodderstedt
> *Sent:* Friday, April 09, 2010 11:57 PM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG
> *Subject:* Re: [OAUTH-WG] Defining a maximum token length?
>
> am supporting the 255 limit (I take no position on the matter – yeah, 
> doesn’t really improve interop since the limit is so high, no one is 
> consensus on this size limit, I don’t think the spec should say 
> [email-masked]  <mailto:[email-masked]>

---

From: Allen Tom <[email-masked]>
Date: Mon, 12 Apr 2010 09:32:58 -0700

+1  on having no limits for the Access Token length.

I  fully acknowledge that shorter is better  in the case where access
tokens are passed on the URL as query parameters (aka jsonp), there are
practical URL length limits. Bigger tokens consume more network resources,
which can be a severe issue for mobile devices. Likewise, not defining the
token size makes it harder to client developers to size their database.

That being said, given that the underlying APIs that are protected by OAuth2
are generally proprietary and are not interoperable, it¹s really up to the
Service Provider to determine the appropriate requirements and limits for
their Access tokens.

Allen

On 4/12/10 2:23 AM, "Anthony Nadalin" <[email-masked]> wrote:

> I would argue that for the spec to provide a token size limit that is greater
> than 255 would cause more harm than good. This is not to say I am supporting
> the 255 limit (I take no position on the matter  yeah, that happens rarely).
> If the spec provided a 4K limit, client libraries are likely to codify that
> which will make them extremely wasteful for 99% of the popular cases on the
> web today. A 4K limit doesn¹t really improve interop since the limit is so
> high, no one is likely to issue even bigger tokens with public APIs.
> 
> The 255 limit keeps the token size within the most effective database field
> size limit for this type of identifier. If we cannot reach consensus on this
> size limit, I don¹t think the spec should say anything. However, if I wrote a
> client library, I would make it use a 255 default size limit and require a
> custom configuration to enable it to use something else.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 12 Apr 2010 13:24:19 -0700

Unless the chairs decide otherwise, I'd say we're done discussing this... The consensus is no limits but to offer guidance so that developers on both side are aware of the need to communicate token sizes.

EHL

On 4/12/10 9:32 AM, "Allen Tom" <[email-masked]> wrote:

I  fully acknowledge that shorter is better - in the case where access tokens are passed on the URL as query parameters (aka jsonp), there are practical URL length limits. Bigger tokens consume more network resources, which can be a severe issue for mobile devices. Likewise, not defining the token size makes it harder to client developers to size their database.

That being said, given that the underlying APIs that are protected by OAuth2 are generally proprietary and are not interoperable, it's really up to the Service Provider to determine the appropriate requirements and limits for their Access tokens.

Allen

+1

256 is much too short

EHL

Allen

________________________________
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Luke Shepard <[email-masked]>
Date: Mon, 12 Apr 2010 15:04:26 -0700

Agreed. Seems that consensus is no limit.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, April 12, 2010 1:24 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Defining a maximum token length?

EHL

Allen

256 is much too short

EHL

Allen