Autenticación OAuth

Gisela Torres
Caminos a la nubes
OAuth es un protocolo abierto que permite autenticarse a través de las API de distintas compañías como por ejemplo Twitt

Autenticación OAuth

Es posible que muchos de vosotros hayáis oído la noticia de que varias de las grandes empresas ya soportan autenticación en sus APIs a través de OAuth. ¿Qué es OAuth y por qué ha venido para quedarse?

OAuth es un protocolo abierto que permite autenticarse a través de las API de distintas compañías como por ejemplo Twitter, Yahoo, Google, etcétera. Hasta hace bien poco uno de los métodos más usados para la autenticación en las mismas era a través de Autenticación Básica con todo lo que ello suponía: el envío de nuestras credenciales con cada petición fácilmente descifrable. Twitter dejará de dar la posibilidad de este tipo de autenticación en el próximo mes.

¿Qué ofrece OAuth?

El objetivo de este método de autenticación es poder acceder a recursos protegidos sin la necesidad de enviar nuestro usuario y contraseña para solicitar los mismos. ¿Cómo es posible? A través de nuestra aplicación será necesario generar una firma que nos identifique gracias a un conjunto de tokens facilitados por el servicio. En este post voy a centrarme en las dos plataformas con las que he estado trabajando estos días: Twitter y Yahoo.

Workflow de OAuth

OAuth-Workflow-diagram

En esta imagen podemos ver cuáles son los pasos para poder solicitar los recursos protegidos de un servicio. El objetivo fundamental es conseguir un Access token  y un Access Token secret. Con ellos seremos capaces de generar la firma necesaria para obtener los recursos protegidos de nuestros usuarios sin necesidad de enviar sus credenciales en cada petición. Los pasos que debemos seguir son los siguientes:

  1. Creación de una aplicación y obtención de una Consumer key y Consumer Secret.
  2. Solicitar un token temporal.
  3. Autorización del usuario.
  4. Intercambio del token temporal y la autorización del usuario por un Access Token y Access Secret Token.

Creación de una aplicación y obtención de una Consumer key y Consumer secret

Lo primero que necesitamos para comenzar es una Consumer key y Consumer Secret. Ambos se consiguen cuando creamos «simbólicamente» una aplicación en cualquiera de las plataformas de la cual queremos hacer uso de sus servicios. En el caso de Twitter, para crear la aplicación, podemos acceder a la siguiente dirección. Por otro lado, en Yahoo podemos realizar la misma operación a través de este otro enlace. Obviamente, es necesario tener una cuenta para poder darlas de alta. Una vez creada, en ambos casos podemos ver en los detalles la Consumer Key y Consumer Secret generadas:

Twitter-app-details
Yahoo-app-details

Solicitar un token temporal

Llegados a este punto es donde comenzamos con la generación de código. Lo primero que necesitamos antes de pedir la autorización del usuario, para recuperar sus datos privados desde nuestra aplicación, es solicitar un token temporal para poder iniciar un proceso de autorización desde la plataforma en cuestión. Para solicitar un token al servicio serán necesarios los siguientes parámetros:

  • oauth_consumer_key: Se obtuvo cuando dimos de alta la aplicación.
  • oauth_signature_method: Se trata del método que utilizaremos para generar la fima. En este post usaré HMAC-SHA1 ya que Twitter solamente soporta este método hasta la fecha, pero también es posible usar PLAINTEXT y RSA-SHA1. Yahoo soporta tanto HMAC-SHA1 como PLAINTEXT.
  • oauth_signature: La firma generada por nuestra aplicación.
  • oauth_nonce: Se trata de un string aleatorio que acompaña a un timestamp.
  • oauth_timestamp: El timestamp está comprendido entre el 1 de Enero de 1970 y la fecha actual y se utiliza de manera conjunta por el servidor con oauth_nonce para verificar que la petición nunca se ha realizado antes y así prevenir ataques.
  • oauth_version: En la actualidad se está utilizando la versión 1.0 de OAuth. Este parámetro es opcional.
  • oauth_callback: Es importante mencionar que es posible utilizar OAuth tanto con aplicaciones de escritorio como aplicaciones web. Es por ello que este parámetro es importante para que el servicio se redirija a esta dirección después de que se autorice el acceso. En el caso de Twitter se puede omitir si la aplicación es de escritorio pero no ocurre lo mismo para el caso de Yahoo, donde debemos especificar este parámetro con el valor oob (Out of bounds).

Estos parámetros serán parte de la cabecera de la petición dentro del apartado Authorization:

Generar nonce

Se trata de un valor usado sólo una vez y simplemente se nos pide la generación de un string diferente para cada petición en las especificaciones oficiales de OAuth. Una implementación válida podría ser la siguiente:

Generar timestamp

Como se explicó en la enumeración de los parámetros necesarios, el timestamp debe estar comprendido entre el 1 de Enero de 1970 y la fecha actual.

Normalizar la url

Si la dirección a la cual debemos realizar la petición utiliza un puerto distinto al usado por defecto en su protocolo, deberemos asignar el puerto en cuestión a la dirección:

Creación de la firma

La firma es quizás la parte más compleja de la aplicación ya que está compuesta de una serie de pasos y si cometemos el error en alguno de ellos, el servidor rechazará la petición sin dar más explicación que un signature_invalid.

Firma base

La firma base, tal y como nos indican en las especificaciones, se trata de la concatenación de el http method utilizado, la url a la que hacemos la petición y el resto de parámetros concatenados y ordenados por nombre y valor.

Firma encriptada y final

Una vez que tenemos los métodos para concatenar y normalizar los parámetros según lo establecido por OAuth, debemos realizar un último paso para obtener la firma que finalmente pasaremos al servicio. En la misma, debemos concatenar primeramente el token  Consumer Secret  y Token Secret si es que lo hubiera con un ampersand(&) entre ellos. Si utilizáramos PLAINTEXT deberíamos utilizar su código correspondiente en Unicode: %26. Si no existiera el segundo integrante, Token Secret, debemos indicar igualmente el ampersand dentro de la cadena.

Por último es necesario hacer uso del algoritmo de hash HMAC-SHA1, generado a partir del Consumer Secret y Token Secret concatenado anteriormente, para cifrar la firma base creada en el apartado anterior. Un método para llevar a cabo estos pasos podría ser el siguiente:

Con este conjunto de métodos para crear un nonce, timestamp y la firma podemos realizar básicamente todas las llamadas que nos son necesarias para establecer ese primer contacto, desde que creamos una aplicación hasta que un usuario accede a establecer conexión con sus datos privados a través de la API usando nuestro cliente.

Llamada al servicio para la obtención del token temporal

Una vez lista la cabecera de nuestra petición, ya podemos realizar la llamada para recuperar el token temporal y un token secret que nos serán útiles para el último paso. Dependiendo del servicio con el que queramos contactar, realizaremos la llamada a una dirección u otra facilitadas por la plataforma:

Para realizar las peticiones podemos utilizar bien WebClient o HttpWebRequest.

Si nos fijamos en el constructor de la clase, lo primero que hacemos es deshabilitar la opción Expect 100 Continue. El propósito de esta propiedad es la posibilidad de que la petición pudiera enviar en primer lugar sólo la cabecera con la autorización, para verificar si efectivamente tenemos permiso de realizar la misma. Si la autenticación fallara devolviendo un 417 nos ahorraríamos el envío de los datos y finalizaría la comunicación. Si por otro lado el servidor devolviera el estado 100 (Continue) el cliente, es decir nuestra aplicación .NET, enviaría el resto del mensaje. Al menos Twitter no soporta este comportamiento y debe ser desactivado para evitar errores imprevistos. La segunda propiedad deshabilitada se utiliza para reducir el tráfico y debe ser anulada también por temas de compatibilidad.

Por otro lado, Realm es el nombre del dominio al que va dirigido aunque no es obligatorio incluirlo.

Una vez realizada la llamada con éxito, recuperamos un conjunto de valores donde podemos encontrar el token temporal necesario para el siguiente paso y el token secret para completar el último. Para recuperarlos, he creado un pequeño método llamado RetrieveToken donde almacenaremos en una clase los valores necesarios de la respuesta:

Autorización del usuario

Una vez que ya hemos obtenido el token temporal, ya podemos solicitar autorización al usuario para poder acceder a sus recursos protegidos. Dependiendo del servicio que estemos utilizando, debemos dirigirnos a su página de autorización con el token temporal como query string. Ejemplos de estas páginas son:

El resultado de esta llamada podría ser parecido a lo siguiente:

Authorize-Twitter
Authorize-Yahoo

Si el usuario acepta, en el caso de Twitter se nos facilitará un número y en Yahoo una cadena de caracteres aleatorios. En cualquiera de los dos casos, este nuevo dato se conoce como oauth_verifier y nos servirá junto con el token temporal y el token secret para finalizar el proceso.

Intercambio del token temporal y la autorización del usuario por un Access Token

Ya estamos en la recta final y solamente debemos realizar una última petición. Ya tenemos todos los ingredientes para conseguir el Access Token e incluso todas las recetas (métodos) para llevar a cabo dicha petición, por lo que solamente necesitamos pasar los valores a nuestro código. En el caso de Twitter y Yahoo las direcciones a las cuales debemos realizar la petición son las siguientes:

Es recomendable realizar la misma a través del método POST. Por otro lado, se adjuntan nuevos parámetros que son: token secret, devuelto en la petición junto con el token temporal, oauth_verifier, el cual se nos facilitó cuando dimos permiso a nuestra aplicación en el paso anterior, y el token temporal en sí que será necesario adjuntarlo en esta ocasión en la cabecera junto con los demás parámetros.

Como podemos ver, los métodos utilizados son los mismos que para solicitar un token temporal, añadiendo los valores que hasta ahora eran parámetros opcionales utilizando el Framework 4.0 de .NET. Una vez que se realice la petición obtendremos el access token y access token secret con el que podremos generar nuestras claves.

Para finalizar, me gustaría comentar que, debido al tiempo que he empleado en realizar este estudio y análisis de cada una de las partes y de lo mucho que me tuve que pegar con ello, he subido una pequeña aplicación a Codeplex que servirá como utilidad y aprendizaje sobre el funcionamiento de OAuth con un ejemplo completo de todo este proceso. Aún estoy realizando cambios para intentar mejorarla pero podéis acceder a la misma a través de esta dirección.

Espero que haya sido de utilidad.

¡Saludos!


Gisela Torres

Gisela Torres trabaja en Microsoft como Cloud Solution Architect. Se trata de un puesto técnico cuya misión es apoyar y asesorar sobre soluciones y arquitecturas cloud utilizando Microsoft Azure como plataforma. Antes de eso trabajo como arquitecta de software y desarrolladora de aplicaciones en varias empresas. Durante esos años recibio varios premios por ejemplo Most Valuable Professional en Microsoft Azure. Le encanta programar y la tecnología en general.

Más artículos de Gisela en su blog - https://www.returngis.net/

Related Posts

Únete a nuestra Newsletter

Lidera la Conversación en la Nube