Saltar al contenido principal

​
OAuth Echo

OAuth Echo es un mecanismo para delegar de forma segura la autorización OAuth con un tercero mientras se interactúa con una API. Hay cuatro partes involucradas en esta interacción:
  • el Usuario que está usando X a través de una aplicación de X concreta y autorizada
  • el Consumidor, o la aplicación de X que intenta interactuar con el proveedor de medios de terceros (por ejemplo, el sitio para compartir fotos)
  • el Delegador, o el proveedor de medios de terceros
  • el Proveedor de Servicio, también conocido como la propia X  
Básicamente, se prepara una solicitud para que el Delegador la envíe a la X API en nombre de una aplicación y de un usuario. Se agrega lo que de otro modo sería una solicitud OAuth firmada en un encabezado HTTP y se le pide al Delegador que envíe esa solicitud a X después de completar la operación intermedia. Por ejemplo: el Usuario quiere subir una foto. El Consumidor va a llamar a upload en el Delegador con un POST. El POST debe contener la imagen, pero también debe contener dos elementos adicionales como encabezados HTTP:
  • x-auth-service-provider — en la práctica, este es el “realm” al que se debe enviar la delegación de identidad; en el caso de X, establézcalo en https://api.x.com/1.1/account/verify_credentials.json. Las integraciones de X basadas en iOS5 agregarán un parámetro adicional application_id a esta URL que también se usará para calcular la oauth_signature utilizada en x-verify-credentials-authorization.
  • x-verify-credentials-authorization — el Consumidor debe crear todos los parámetros OAuth necesarios para poder llamar a https://api.x.com/1.1/account/verify_credentials.json usando OAuth en el encabezado HTTP (por ejemplo, debería verse como OAuth oauth_consumer_key=”...”, oauth_token=”...”, oauth_signature_method=”...”, oauth_signature=”...”, oauth_timestamp=”...”, oauth_nonce=”...”, oauth_version=”...” ).  
Tenga en cuenta que toda la transacción debe ocurrir dentro de un período de tiempo en el que el oauth_timestamp siga siendo válido. Como alternativa, en lugar de enviar estos dos parámetros en el encabezado, se podrían enviar en el POST como x_auth_service_provider y x_verify_credentials_authorization; en este caso, recuerde escapar e incluir los parámetros en la cadena base de la firma OAuth, de forma similar a como se codifican los parámetros en cualquier solicitud. Es preferible usar encabezados HTTP para mantener las operaciones lo más separadas posible. El objetivo del Delegador, en este punto, es verificar que el Usuario es quien dice ser antes de guardar el contenido multimedia. Una vez que el Delegador reciba todos los datos anteriores a través de su método de carga, debería almacenar temporalmente la imagen y luego construir una llamada al endpoint especificado en el encabezado x-auth-service-provider, en este caso https://api.x.com/1.1/account/verify_credentials.json, usando el mismo encabezado de autenticación OAuth proporcionado por el Consumidor en el encabezado x-verify-credentials-authorization.  

​
Mejores prácticas de OAuth Echo

Utiliza la URL proporcionada por x-auth-service-provider para realizar la consulta, no un valor codificado de forma fija. Apple iOS, por ejemplo, agrega un parámetro adicional application_id a todas las solicitudes OAuth, y este debe conservarse en cada etapa de OAuth Echo. Para la parte de autorización de OAuth, toma el valor del encabezado en x-verify-credentials-authorization y colócalo en su propio encabezado Authorization para su llamada al proveedor de servicios. Para mayor seguridad, confirma que el valor en x-auth-service-provider sea el que debería ser.
  • Si el proveedor de servicios devuelve un HTTP 200, entonces todo está correcto. El Delegador debe almacenar permanentemente la imagen, generar una URL y devolverla.
  • Si el proveedor de servicios no devuelve un HTTP 200, entonces descarta la imagen y devuelve un error al Consumidor.