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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
