Introducción a oAuth

Con el crecimiento de servicios en línea que exponen APIs para su consumo desde servicios o productos de terceros, se presenta el problema de cómo otorgar acceso seguro a la cuenta del usuario por parte del desarrollador al mismo tiempo que se mantengan confidenciales las credenciales del usuario. Ante este problema, a finales de 2006 Blaine Cook, Chris Messina, David Recordon y Larry Halff entre otros, discutían la posible solución que en ese entonces se basaba en el uso de OpenID, y al analizarlo llegaron a la conclusión de que no existía una forma práctica y estandarizada para delegar el acceso a APIs. Fue así que en abril de 2007 crearon un grupo de discusión para generar una solución a esta necesidad, y el 3 de octubre de 2007 finalmente fue liberada la versión 1.0 de la especificación de oAuth.

oAuth es un estándar abierto y simple para la autenticación segura de APIs. Permite al usuario final otorgar acceso a sus recursos privados en un sitio (llamado Proveedor de Servicio) a otro sitio (llamado Consumidor, no confundir con el Usuario). Una analogía con el mundo real es el escenario de la llave de auto especial para valet parking la cual dejamos al chofer del valet. A diferencia de la llave normal, con la llave de valet solo es posible manejar el auto una cierta distancia e inclusive tampoco es posible abrir la cajuela o guantera. oAuth no es un concepto nuevo, únicamente reúne los conocimientos y mejores prácticas de protocolos existentes en la industria dentro de una única especificación bien definida y abierta. oAuth es similar a otros protocolos usados en la actualidad tales como: Flickr API, Amazon Web Services API, Google AuthSub y Yahoo BBAuth entre otros. Actualmente existen ya varios servicios que utilizan oAuth, siendo los más populares Digg, Jaiku, Flickr, Plaxo, y Twitter entre otros. La lista aumenta continuamente, y rápidamente oAuth se está convirtiendo en el mecanismo default para que dos servicios en Internet puedan compartir información o recursos sobre un usuario.

¿Cómo funciona?

Para entender como funciona oAuth primero necesitamos definir algunos conceptos fundamentales:

• Proveedor de Servicio. Controla todos los aspectos de una implementación de oAuth. El Proveedor de Servicio es el término empleado para describir al sitio web o servicio web donde están localizados los recursos restringidos. Puede ser un sitio para compartir fotografías, un servicio de banca en línea, un servicio de microblogging o cualquier otro donde se almacene información privada de los usuarios. oAuth no obliga que el Proveedor de Servicio también sea el proveedor de identidad, lo que significa que el Proveedor de Servicio puede usar sus propios nombres de usuario y contraseñas para autenticar a sus usuarios o bien utilizar otros sistemas como OpenID.
• Usuario. Los usuarios tienen información y recursos que no quieren que sean públicos en el Proveedor de Servicio pero que quieren compartir con otro sitio. En oAuth el protocolo se detiene requiriendo interacción manual del usuario por lo menos una vez para recibir la autorización explícita de acceso.
• Consumidor. Es el término otorgado a la aplicación que trata de acceder a los recursos privados del Usuario, tal vez sería más adecuado llamarlo Consumidor de Servicio para ser consistentes y evitar confusiones. Puede ser un sitio web, una aplicación de escritorio, un dispositivo móvil o cualquier otro dispositivo conectado a Internet. El Consumidor es el que obtiene el permiso para acceder a los recursos y donde se realiza la mayor parte del proceso de oAuth. El Proveedor de Servicio genera para el Consumidor información técnica para realizar la implementación como el Consumer Key (llave del consumidor) y el Consumer Secret (secreto del consumidor).
• Recursos Protegidos. Todo lo que oAuth protege y a lo que permite el acceso. Puede ser información (fotografías, documentos, contactos, etc.), acciones (publicar en un blog, transferir fondos, agregar contactos, enviar mensajes, etc.) o cualquier URL con la necesidad de restringir su acceso.
• Tokens. oAuth utiliza tokens en lugar de credenciales de usuario para acceder a los recursos. Un token generalmente es una cadena aleatoria alfanumérica que es única, difícil de adivinar, y que tiene que usarse en par con el Consumer Secret para evitar el abuso del token. oAuth define dos tipos de tokens: Request (petición) y Access (acceso).

Para iniciar cualquier flujo de oAuth es necesario que existan un Proveedor de Servicios y un Consumidor, por lo que desde el punto de vista del desarrollador lo primero que hay que hacer es registrar una aplicación de Consumidor ante un Proveedor de Servicio existente. El Proveedor de Servicio nos solicitará datos sobre nuestra aplicación (nombre, autor, URL, etc.) y al registrarnos nos asignará dos datos importantes: Consumer Key y Consumer Secret, los cuales son únicos y debemos de mantener privados. Adicionalmente, el Proveedor de Servicio provee documentación sobre las URLs y métodos de autorización.

Flujo de trabajo

Una vez que se ha implementado satisfactoriamente oAuth en la aplicación Consumidor, el Usuario puede iniciar el proceso de autorización para utilizar la aplicación consumidor y que ésta tenga acceso a los recursos en el Proveedor de Servicio. La figura 1 muestra este proceso de autorización.

1. El usuario ingresa a la aplicación Consumidor y al momento de intentar acceder los recursos privados se dispara el proceso con la solicitud de un Request Token por parte del Consumidor hacia el Proveedor de Servicio quien verificará que sea una solicitud válida y entonces generará el Request Token solicitado para el Consumidor.
2. Al recibir el Request Token el Consumidor redireccionará al Usuario hasta el sitio web del Proveedor de Servicio para que manualmente el usuario se autentique con sus credenciales y autorice explícitamente la solicitud de acceso del Consumidor. Una vez hecho esto el Proveedor de Servicio redirige al usuario nuevamente hacia la aplicación Consumidor. Es importante hacer notar que las credenciales son ingresadas por el Usuario dentro del sitio del Proveedor de Servicio y no en la aplicación Consumidor, por lo que este último nunca tiene acceso a ellas.
3. El Consumidor una vez autorizado procede a realizar el intercambio del Request Token por el Access Token. El Request Token únicamente sirve para la aprobación de acceso por parte del Usuario mientras que el Access Token es el que se utiliza para acceder a los Recursos Protegidos.
4. Finalmente utilizando el Access Token el Consumidor accede a los Recursos Protegidos, pudiéndolo hacer en una o más solicitudes subsecuentes sin necesidad de volver a solicitar la autorización del Usuario.

Los parámetros de oAuth que son enviados con cada solicitud son:

• oauth_consumer_key - El identificador del consumidor.
• oauth_signature - Firma generada por el consumidor para que el proveedor autentique la operación.
• oauth_signature_method - El método utilizado para la firma (HMAC_SHA1, RSA-SHA1, PLAINTEXT).
• oauth_token - El valor del token que asocia la petición del usuario con el proveedor de servicio.
• oauth_timestamp - Timestamp de la operación.
• oauth_nonce - Cadena única generada por el consumidor para que el proveedor de servicio verifique que esta operación no se ha hecho anteriormente, y así proteger contra ataques de repetición de operaciones.

Estos parámetros se transmiten mediante el header de autorización HTTP, el HTTP POST Request Body o como parámetros del Query String en el URL. Mediante oauth_timestamp y oauth_nonce se verifica que los requests sean únicos además que con los parámetros encriptados utilizados para firmar los request es posible identificar al Consumidor.

oAuth está diseñado para comunicaciones no seguras (HTTP) y soporta los métodos HMAC-SHA1 y RSA-SHA1 aunque también soporta PLAINTEXT el cual únicamente debe ser usado bajo comunicaciones seguras (HTTPS).

Implementaciones y librerías de referencia

Actualmente existen varias implementaciones de oAuth en múltiples lenguajes de programación lo cual facilita aún más su integración en nuestras aplicaciones. En el sitio oficial de oAuth podemos encontrar un listado de bibliotecas de código para los lenguajes más populares.

oAuth y OpenID

Una de las principales confusiones que existe es en cuanto a la relación entre oAuth y OpenID. oAuth no sustituye a OpenID, sino que son complementarios. oAuth no es tampoco una extensión de OpenID. OpenID se enfoca en la autenticación, utilizando una única identidad para firmarse en varios sitios. Por otro lado, oAuth se enfoca en la autorización, permitiendo acceder a información privada sin compartir por completo la identidad.

Referencias:

1. Sitio Oficial oAuth. http://oauth.net
2. Bibliotecas de Código http://oauth.net/code
3. E. Hammer-Lahav, “The oAuth Core 1.0 Protocol Draft”, Internet Engineering Task Force (IETF). http://bit.ly/sg27r3