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

Hi David,

I wouldn't restrict the length of a tokens to 255 characters, especially 
for access tokens.

Our proprietary token service today uses a token type combination 
similar to OAUTH refresh and access tokens. Based on our experiences I 
would assume the following characteristics of a large-scale OAuth 2.0 
implementation.

Access tokens: Autonomous (w/o callback to authorization server) token 
validation and access control on the service side requires to put all 
relevant user/consumer data into the access token. So access token would 
contain the following data: User Id, Consumer id, context(s), validity, 
authentication methods, user attributes, user permissions, digital 
signature, token id

For our token format, access token length would vary between 200 and 700 
Bytes.

Refresh tokens: in order to refuse refreshing requests for outdated 
tokens early and w/o database access, an authorization server would 
probably put a lot of data into refresh tokens: User Id, Consumer id, 
context(s), validity, authentication methods, digital signature

For our token format, refresh tokens length would be about 200 Bytes. 
 From my perspective, refresh tokens are a typical candidates for 
long-therm database storage on the consumer side. So limiting the length 
would be acceptable, if there is a real benefit. Length limitations 
could also be beneficially for the authorization server since it needs 
to lookup refresh tokens often.

Regarding request payload length: For GET request there is the typical 
header length limitation. POST requests may contain an virtually 
unlimited size of data, even SAML assertion of > 10 Kb could be passed 
w/o any problem :-)

Limiting the length of the client key is ok.

The length of client secrets is somehow related to the algorithms used 
for consumer authentication. So a 255-chars restriction would probably 
raise issues when using public key crypthography.

regards,
Torsten.
> 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?
>
> The OAuth 1.0 protocol specifically states:
> Clients should avoid making assumptions about the size of tokens and
> other server-generated values, which are left undefined by this
> specification.
>
> That seems like a poor idea when it comes to implementability of the
> technology.  Why did OAuth 1.0 make that decision?
>
> --David
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>    