El protocolo de autenticación OAuth. Flujo de Autenticación (III)

Una vez que conocemos los actores que intervienen en la autenticación por OAuth, veamos cómo se lleva a cabo.

Cuando queremos desarrollar una aplicación (un cliente) para un servicio (twitter para continuar con nuestro ejemplo de la entrada anterior), lo primero que hay que hacer es registrar la que será nuestra aplicación. En ese momento, twitter nos dará un par de credenciales de cliente (o lo que es lo mismo, el consumer key y el consumer secret) con las que nuestra aplicación deberá firmar todas las peticiones que realice a los servidores de twitter.

Veamos el flujo completo en el siguiente diagrama. Las flechas de color rojo se corresponden con las peticiones que realiza el cliente a twitter. Las verdes son respuestas de twitter al cliente. La flecha de color azul se corresponde con el proceso que realiza el usuario a mano:

Flujo OAuth.

Cuando un usuario quiera utilizar nuestro cliente, lo primero que tendrá que hacer éste último es solicitar a twitter unas credenciales temporales (request token y request secret). Este proceso se corresponde con los pasos 1 y 2 del diagrama.

A continuación, nuestro cliente redirigirá al usuario a la Web de twitter (paso 3) indicando el request token que se nos ha facilitado. El usuario inicia sesión en twitter, que le preguntará si autoriza a nuestra aplicación a acceder a sus recursos (paso 4).

Suponiendo que el cliente autorice la aplicación, twitter redirigirá de vuelta al usuario a nuestro cliente si éste se tratara de una aplicación Web (paso 5). En esta petición se indicará un PIN denominado oauth_verifier que será utilizado más adelante.

Para que la redirección sea posible, cuando se solicitan las credenciales temporales en el paso 1, también se indica la URL a la que queremos que twitter redirija al usuario.

En el caso de que nuestro cliente sea una aplicación de escritorio, de teléfono móvil, etc. (en general cualquiera a la que no se pueda realizar la redirección) se sustituye la URL de callback por el valor "oob" (out-of-band). Esto indicará a twitter que basta con que comunique al usuario el oauth_verifier para que sea éste quien lo introduzca directamente en el cliente.

Una vez que el cliente conoce el oauth_verifier, lo envía de vuelta a twitter para solicitar el token de usuario. El servidor responderá a esta petición con el access token y access secret (pasos 6 y 7), lo que finaliza la autenticación por OAuth.

Todas las peticiones que el cliente realice a partir de ese momento, irán firmadas por una combinación del consumer secret y el access secret. De este modo, se identifica en todo momento al usuario y el cliente desde el que se realiza la petición y, de este modo, twitter puede determinar a qué información puede tener acceso y a cuál no.

El flujo descrito es el proceso de autenticación habitual a través de OAuth pero no es el único. Éste se conoce como 3-legged porque en él intervienen los tres actores habituales. Otro flujo que se suele utilizar es el llamado 2-legged en el que el usuario no interviene (sólo hay que autenticar a la aplicación) debido a que no se accede a sus recursos.

¡Hasta la próxima entrada!