2009-07-12 31 views

Respuesta

11

No estoy seguro de que haya algún límite explícito. El spec doesn't have any. Dicho esto, los tokens OAuth a menudo se pasan como parámetros de url y, por lo tanto, tienen algunas de las mismas limitaciones. es decir, debe estar codificado correctamente, etc.

1

Un token de OAuth es conceptualmente una secuencia de bytes de tamaño arbitrario, no caracteres. En las direcciones URL, que se codifica mediante mecanismos estándar escapar URL:

unreserved = ALPHA, DIGIT, '-', '.', '_', '~' 

Todo lo que no consigue sin reservas% codificados en.

No estoy seguro si solo habla sobre el parámetro oauth_token que se pasa. Por lo general, los parámetros adicionales deben almacenarse y transmitirse también, como oauth_token_secret, oauth_signature, etc. Algunos de ellos tienen diferentes tipos de datos, por ejemplo, oauth_timestamp es un número entero que representa segundos desde 1970 (codificado en dígitos ASCII decimales).

+2

Google+ usa barra "/" para su OAuth 2.0 "código" también: '' código = 4/rymOMYEWum5IN20h0mXts9in0mRf'' –

4

OAuth no especifica el formato ni el contenido de un token. Simplemente usamos pares de nombre-valor encriptados como token. Puede usar cualquier carácter en el token, pero es mucho más fácil de manejar si el token es URL-safe. Logramos esto codificando el texto cifrado con un Base64 seguro para URL.

2

Como mucha gente ya ha señalado. La especificación OAuth no le da la exacta direcciones pero que diga ...

citados a partir de: http://tools.ietf.org/html/draft-hammer-oauth-10#section-4.9

"Servidores deben tener cuidado para asignar -secretos compartidos que son lo suficientemente largo, y al azar suficiente, para resistir tales ataques durante al menos la duración de vez que los secretos compartidos son válidos ".

"Por supuesto, se insta a los servidores a errar en el lado de la precaución, y utilizar el secretos más largos razonables."

por el contrario, se debe considerar la longitud de la URL máximo de navegadores:

véase: http://www.boutell.com/newfaq/misc/urllength.html

2

Si usted lee la especificación, se dice,

El servidor de autorización emite un cliente registrado
identificador - una cadena única que representa el registro
proporciona información d por el cliente. El identificador del cliente no es un secreto
; está expuesto al propietario del recurso y NO DEBE utilizarse
solo para la autenticación del cliente. El identificador de cliente es exclusivo de
el servidor de autorizaciones.

El tamaño del string del identificador del cliente no está definido por esta especificación
. El cliente debe evitar hacer suposiciones sobre el tamaño del identificador
. El servidor de autorización DEBE documentar el tamaño
de cualquier identificador que emita.

En segundo lugar, el token de acceso debe enviarse como encabezado, no como un parámetro de URL.

Autorización: Portador < token>.

-4

Para ser específico, incluso si la especificación de Oauth no dice nada, si está usando java y mysql, entonces será de 16 caracteres, ya que generalmente generamos los tokens usando UUID y lo almacenamos como BINARIO (16) en la base de datos . Conozco estos detalles ya que recientemente hice el desarrollo usando OAuth.

+0

¿Quién es "nosotros" en esta respuesta? –

+0

Quise decir "desarrolladores" por "nosotros" –

0

Los caracteres válidos para el token OAuth están limitados por las restricciones de valores del encabezado HTTP, ya que el token OAuth se envía con frecuencia en el encabezado HTTP "Autorización".

Los caracteres válidos para encabezados HTTP están especificados en https://tools.ietf.org/html/rfc7230#section-3.2.6. Alternativamente puede revisar cabecera HTTP de código de validación de algunas bibliotecas de cliente HTTP populares, por ejemplo, ver Headers.checkNameAndValue() util del marco OkHttp: https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Headers.java

Y esto no es todo. No incluiría el separador de encabezado HTTP (y muchos otros) y los símbolos de espacio en blanco ('' y '\ t') y comillas dobles (") (ver https://tools.ietf.org/html/rfc7230#section-3.2.6) ya que sería necesario escapar el token OAuth antes de usarlo en el encabezado HTTP. Los humanos suelen utilizar tokens en las solicitudes de prueba curl, por lo que los buenos generadores de tokens no agregan dichos caracteres. Pero debe verificar qué caracteres pueden generar el generador de tokens de Oauth con el que funciona su servicio antes de hacer suposiciones.

Cuestiones relacionadas