1 de agosto de 2011

El protocolo de autenticación OAuth. Conceptos (II)

Cuando se lee documentación sobre OAuth se ven una serie de conceptos que, aunque sencillos, en algunos casos pueden llevar a confusiones debido a que la terminología se modificó en algún punto del desarrollo. De esta manera, hay documentos que utilizan la terminología "antigua" mientras que la RFC oficial y la mayor parte de documentos recientes utilizan los términos actuales.

twitter es un servicio que utiliza OAuth para llevar a cabo la autenticación de usuarios desde aplicaciones de terceros, ya sean Web, de escritorio o para dispositivos móviles. Por este motivo, voy a utilizar twitter como ejemplo para identificar cada uno de los términos que paso a describir:

Servidor /server/ (inicialmente llamado Service Provider)
Es quien proporciona el servicio; es decir, allí donde nos estamos intentando autenticar para acceder a sus funcionalidades. En nuestro caso serían los propios servidores de twitter.

Cliente /client/ (antes llamado Consumer)
Es la entidad desde la que se lleva a cabo la autenticación. Cualquier cliente de escritorio, extensión de navegador, cliente para dispositivos móviles... que trabaje con twitter se considera un cliente. Por tanto, se puede decir que es la "aplicación de terceros" desde la que intentaríamos acceder a nuestra información en twitter.

Dueño o Propietario del recurso /Resource Owner/ (antes llamado User)
Como el propio nombre indica, es el propietario del recurso al que se quiere acceder. En nuestro ejemplo seríamos los usuarios finales de twitter.

De esta última definición se puede deducir un nuevo concepto: Recurso protegido /Protected resource/ que sería el recurso (información, funcionalidad...) ubicado en el Servidor al que estamos intentando acceder y que pertenecería a su Propietario.

Por otro lado, se suele diferenciar entre tres tipos de credenciales: cliente, temporales y token. Todas ellas se están formadas por un identificador único y por un secreto (algo parecido al típico usuario/contraseña, aunque no es del todo igual).

Como sucedía con los conceptos anteriores, en alguna documentación se puede encontrar otros nombres para cada par de los anteriores credenciales. De este modo tendríamos consumer key y secret (cliente), request token y secret (temporales) y access token y secret (o incluso user token y secret para el token).

Las credenciales de cliente se utilizan para que el servidor pueda identificar a un cliente determinado. De este modo, el servidor sabe en todo momento qué tipo de cliente está accediendo y podría dar funcionalidades extra a clientes de confianza o con ciertos privilegios. En el caso de twitter, ésta avisó de que toda aplicación que publicara sus credenciales clientes sería deshabilitada (lo siento pero no encuentro la noticia).

Las temporales se utilizan durante el proceso de autenticación de un usuario final (dueño del recurso) y, como su propio nombre indica, su validez es temporal mientras se acuerda el token que será utilizado durante la sesión.

El token sería el equivalente a un identificador de sesión en una aplicación Web estándar y se utiliza para identificar tanto al cliente como al usuario que accede a sus recursos.

Creo que por hoy ya está bien. En la próxima entrada explicaré cómo se obtienen cada una de estas credenciales y cómo interactúan las partes implicadas.

¡Hasta la próxima!