Español | English
rss facebook linkedin Twitter

OAuth - Open Authorization Protocol

Cuando en 2006 los ingenieros de twitter estaban tratando de implementar OpenID para permitir a los desarrolladores de aplicaciones acceder a su API sin que los usuarios tuvieran que introducir sus credenciales en la propia aplicación, se dieron cuenta, por un lado, de que OpenID no era la solución que necesitaban y, más importante aún, de que no existía ningún estándar que permitiera hacer algo parecido.

Comenzaron entonces a trabajar en la implementación de OAuth, que pronto fue apoyada por otras empresas como Google. Hasta que por fin, en octubre de 2007, se publicó OAuth 1.0. Aunque no fue hasta agosto de 2010 que no se aprobó como estándar RFC 5849.

Pero, ¿cómo funciona OAuth y cómo soluciona el problema de que el usuario tenga que introducir sus credenciales en una aplicación de un tercero para acceder a otro servicio?

Antes de explicarlo, voy a introducir unos conceptos que son usados en toda documentación referente a OAuth:
  • Service Provider: La aplicación web que permite acceder via OAuth.
  • User (usuario): Cualquiera que tenga una cuenta en el Service Provider.
  • Consumer: Aplicación de un tercero que usa OAuth para acceder al Service Provider en nombre de un usuario.
  • Protected Resource: Recurso (normalmente información aunque también puede ser una funcionalidad) al que se desea acceder y que se almacena en el Service Provider.
  • Consemer Key / Consumer Secret: Par de identificador / secreto que sirven para que el Consumer pueda identificarse frente al Service Provider.
  • Request Token / Request Secret: Par de identificador / secreto de carácter temporal que es utilizado por el Consumer para que el usuario autorice al Consumer a acceder a sus recursos frente al Service Provider.
  • Access Token / Access Secret: Par de identificador / secreto usado por el Consumer para acceder a los recursos del Service Provider una vez que el usuario lo ha autorizado.
Y ahora sí, veamos cómo funciona el protocolo con un ejemplo y utilizando la siguiente imagen como punto de referencia.






Imaginemos que un usuario de twitter acaba de instalarse un cliente para acceder a su cuenta desde su móvil. En esta situación se identifican 3 papeles: el usuario; la aplicación, que se corresponde con el Consumer en el gráfico y lógicamente twitter, que sería el Service Provider.

Lo primero que sucede cuando el usuario inicia la aplicación en su móvil, es que ésta se pone en contacto con twitter y le solicita unas credenciales temporales para poder identificar el proceso de autenticación. Esa petición (la flecha 1 en el diagrama) va firmada con el Consumer Key y el Consumer Secret que identifican a la aplicación y que son proporcionadas por twitter al desarrollador cuando éste la registra como aplicación válida en twitter.

Ante esta petición, twitter responde con el Request Token y el Request Secret que son las credenciales temporales que necesita la aplicación (flecha número 2). Ahora se dirige al usuario al Service Provider (flecha número 3), en este caso twitter, indicando en la petición el Request Token que identifica el proceso de autenticación.

Cuando el usuario llega a twitter, si no tiene la sesión abierta se le pide que inicie sesión normalmente para preguntarle después si autoriza a la aplicación a acceder a sus datos (flecha número 4).

El modo en que se redirige al usuario de vuelta a la aplicación (flecha número 5) depende de la implementación de cada caso. En algunas ocasiones el proceso es automático y transparente para el usuario pero en otros casos, lo que se hace es que el Service Provider le devuelve un código PIN al usuario que éste tiene que introducir manualmente en la aplicación (Consumer). La diferencia entre las dos posibilidades radica en si el usuario tiene que intervenir o no, pero en ambos casos la aplicación tiene que haber recibido el código PIN que el Service Provider generó.

Una vez que la aplicación conoce el PIN, solicita al Service Provider las credenciales finales que se utilizarán a partir de ese momento (flecha número 6). En esa petición se indican el PIN que se asignó al usuario cuando autorizó la aplicación en el Service Provider (de este modo se identifica al usuario) y se firma con el Request Token y Request Secret (para identificar la aplicación y el proceso de autenticación).

Si todo el proceso se ha realizado correctamente, el Service Provider (twitter) le devuelve a la aplicación el Access Token y el Access Secret que se utilizarán a partir de ese momento para firmar todas las peticiones que se realicen y que identifican al usuario y a la aplicación.

Así que resumiendo, después de todo el proceso, twitter es capaz de identificar a través de todas las peticiones desde qué aplicación se está accediendo y en nombre de qué usuario y el usuario tan sólo se ha autenticado en la página oficial de twitter, sin meter su contraseña en una aplicación que no conoce.

Desde el punto de vista de la seguridad, el protocolo tan sólo resuelve el problema de que el servidor pueda identificar al usuario y a la aplicación y provee de un mecanismo para verificar la integridad de todas las peticiones mediante firma digital (aunque esto último no es siempre así...). El protocolo, también, proporciona mecanismos para evitar ataques de replay para evitar que una petición capturada pueda ser utilizada desde otra aplicación para acceder a los datos del usuario fingiendo ser la aplicación autorizada.

Para asegurar todo el proceso, es necesario que tanto el Service Provider como las aplicaciones (consumers) implementen una serie de medidas, como por ejemplo implementar HMAC-SHA1 ó RSA-SHA1 si el canal de comunicación entre el Service Provider y el Consumer no fuera seguro (que es lo más habitual).

Otros ejemplos son proteger frente a CSRF la aplicación consumer en caso de que se trate de una aplicación web; proteger frente a Clickjacking la web del Service Provider en la que el usuario autoriza la aplicación; utilizar un algoritmo con una alta entropía para generar los pares tokens/secrets y, sobre todo, proteger frente accesos no autorizados la base de datos del Service Provider en la que se almacenan todos los pares ya que, a diferencia de las contraseñas de las que se recomienda almacenar tan sólo su función hash, los secrets tienen que almacenarse en claro para poder implementar el protocolo y un acceso a dicha base de datos sería equivalente a publicar un listado de usuarios/contraseñas.

Julio Gómez Ortega
Dept. ACSS S21SEC
 

1 comentario:

Javi Puerta dijo...

Buen post Julio.

Un abrazo,


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login