PaaSOS – TipeSoft – Servicios empresariales en la nube.

Ahora que ya sabemos de que hablamos (Servicios Web – I y Servicios Web – II) os proponemos un ejercicio. Nosotros ya lo hicimos en su momento y es enriquecedor para la nueva etapa que Velneo V7 introducirá con la llegada de QML y JavaScript.

Intentaremos explicar paso a paso como realizar un cliente de twitter básico mediante OAuth y API’s REST/XML.

Conceptos básicos OAuth: Usuarios, OAuth Consumer y OAuth Service Provider

Para poder hablar de OAuth, se necesitan tres partes, un servidor o proveedor de servicios, usuarios y un consumidor:

• OAuth Service Provider o proveedor de servicios OAuth: Sitios o servicios web que contienen información de usuarios cuyo acceso es restringido. Algunos de los más conocidos son Facebook, Twitter o Youtube. Estos proveedores ponen a disposición de los desarrolladores una API que soporta el protocolo de autenticación OAuth.
• Usuarios: Sin los usuarios, no existiría OAuth. Por usuario se entiende cualquier persona que tiene una cuenta de usuario en un Service Provider.
• OAuth Consumer: Cualquier sitio o aplicación web, móvil o de escritorio que solicita permiso a un usuario para acceder a sus datos de acceso restringido que alberga un Service Provider. El usuario puede autorizar o denegar el acceso del consumer a sus datos.

API Key y Callback URL

Cada OAuth Service Provider os proporcionará un API Key (un string de letras y números) para identificar que las peticiones que recibe mediante su API vienen de un OAuth Consumer autorizado, es decir, vuestra aplicación.

A su vez, cada OAuth Service Provider os pedirá que indiquéis un Callback URL, es decir, una dirección URL que apunte a un archivo de vuestra aplicación el cual se encargará de procesar la respuesta de autorización (o desautorización) de acceso a los datos de la cuenta del Usuario en el OAuth Service Provider.

Fujo en OAuth 1.0a

• Obtenemos un Request Token
• Solicitamos la autorización del Usuario (para acceder a los datos de su cuenta) enviándole a una página especial de login del Service Provider.
• Cambiamos el Request Token por un Access Token

Punto de partida

Como punto de partida utilizaremos un ejemplo implementado íntegramente en QML y javascript (https://gitorious.org/qt-qml-demo-playground/qt-qml-demo-playground/trees/master/twitter-oauth)

Este ejemplo contiene dos librerías javascript importantes:

• sha1.js: Una librería que implementa SHA-1
• OAuth.js: Una librería que implementa OAuth 1 (no usar en producción)

Obtenemos un Request Token

Realizamos la solicitud del token (OAuth.qml – línea 70):

Obteniendo el token y la clave secreta (línea 78 y 79).

Solicitamos la autorización del Usuario (para acceder a los datos de su cuenta) enviándole a una página especial de login del Service Provider.

Preparamos la petición de autorización (línea 83).

Realizamos la petición de autorización (línea 88).

Rellenamos los datos de autenticación (línea 94 y 95).

Aceptamos el formulario (Línea 96)

Cambiamos el Request Token por un Access Token

Para ello recogemos el pin (línea 99).

Componemos una nueva solicitud (en este caso para el access_token) pasándole como parámetros el pin, token y secret (línea 100).

Ya estamos autenticados.

Realizamos las llamadas a la API

Ahora que estamos autenticados podemos realizar cualquier llamada a la API de twitter, por ejemplo… a la timeline.

Esperamos que esta introducción os sea de ayuda para hacer vuestro primeros pinitos con OAuth.

¿Te gustaría tener un cliente de Facebook o twitter integrado en tú aplicación empresarial?

Desde hace unos meses estamos trabajando en sendos clientes de twitter y facebook para PaaSOS. Estos dos clientes están implementados íntegramente mediante QML y JavaScript. Llegado el momento serán 100% funcionales en Velneo V7.

Se utilizan las API REST de twitter y facebook. También se utilizan los protocolos de Autenticación OAuth 1a y 2 por lo son un buen punto de partida para el estudio de la implementación mediante javascript de sendos clientes para API’s REST y OAuth .

Fuente original: http://jordisan.net/proyectos/Autent_y_auth-J_Sanchez.pdf

Con la proliferación de los servicios web en Internet, surgió un problema de relevancia, la autenticación. Los servicios disponibles han crecido enormemente, y la mayoría de usuarios utilizan  múltiples aplicaciones de terceros: por ejemplo, un usuario consulta su correo en un sistema de webmail, desde el teléfono o desde su cliente de correo. También es habitual la participación en redes sociales como facebook, linkedin, tuenti o twitter, etc. La mayoría de esas aplicaciones requieren que el usuario se autentique; es decir, que demuestre de algún modo (habitualmente usando un identificador de usuario único y una contraseña asociada) que es quien dice ser.

Al tratarse de aplicaciones independientes entre sí, en principio cada una de ellas utilizaría  su propio sistema de autenticación y de gestión de datos personales, lo cual implica inconvenientes al usuario cada vez más graves a medida que el número de sistemas que utiliza crece.

Surge la necesidad de conocer cuales son las tendencias actuales respecto a la autenticación y autorización en Internet.

Autenticación vs. autorización

Antes de seguir, es necesario hacer una distinción clara entre dos tipos de servicios ofrecidos por las tecnologías que vamos a describir.

• Autenticación: consiste en un sistema para certificar que el usuario es quien dice ser; lo más común es utilizar una combinación de identificador de usuario único y contraseña.
• Autorización: consiste en dar acceso a una serie de recursos a un usuario o sistema (para ello, el usuario o el sistema previamente tendrán que haberse autenticado).

Protocolos y estándares ampliamente adoptados

Una primera solución evidente al problema de la autenticación sería el uso  de algún tipo de certificado personal (basado, por ejemplo, en el estándar X.509) emitido y validado por alguna autoridad central  de confianza. Si bien este tipo de certificados son útiles para gestiones  con determinadas entidades,  no son prácticos en general para el acceso a servicios de Internet. Por este motivo han surgido varios protocolos de autenticación y autorización en Internet.

OpenID

El protocolo abierto OpenID, cuya primera versión fue definida en 2005 para su uso en el sitio web LiveJournal, es un protocolo de autenticación federada, y consiste básicamente en que el usuario selecciona un servidor externo (el “proveedor” de OpenID) que va a ser el que va a validar su identidad en un sistema determinado (el “consumidor” de OpenID).

Problemas de OpenID:

• Complejidad: no se implementa fácilmente.
• Seguridad: es un protocolo muy vulnerable al  phishing.
• Privacidad: los proveedores de OpenID tendrán mucha información del usuario.
• Confianza: ¿quién es realmente el usuario?.
• Usabilidad: puede ser incómodo  y/o complejo  para el usuario.
• Adopción: los proveedores de servicios tienen pocos motivos para aceptarlo como autenticación.
• Disponibilidad: se incrementa la dependencia de servidores.
• Patentes: no es un protocolo “tan” abierto.

OAuth

El protocolo abierto OAuth, a diferencia de OpenID, es un protocolo de autorización; más exactamente, de delegación de acceso; es decir, permite definir cómo un tercero va a acceder a los  recursos propios. Empezó a definirse en 2006 y en 2007 se publicó la primera versión oficial.  El propósito de este protocolo es, pues, que un usuario que tiene determinados recursos en un servidor (el “proveedor” de OAuth) pueda dar acceso a un tercero (el “consumidor”, usualmente un sitio web) a parte o todos esos recursos, sin necesidad de que ese tercero conozca su usuario y contraseña, ya que con esos datos tendría el control total de la cuenta.

Problemas de OAuth:

• Complejidad.
• Orientado a navegadores.
• Seguridad.

OAuth 2.0

OAuth 2.0  pretende ser una versión revisada y simplificada de OAuth. Aventaja a la versión anterior en una mayor simplicidad de implementación, y en una arquitectura más robusta y que da soporte a mayor número de plataformas.

Existe cierta confusión sobre si OAuth es o no un protocolo de autenticación de usuario. Estrictamente hablando  no lo es, ya que no define ningún mecanismo  explícito destinado a autenticar la identidad del usuario. Por tanto, cuando se habla del  “mecanismo de autenticación de OAuth”, en realidad  se están refiriendo al mecanismo de autenticación propio del sitio web proveedor de OAuth, que puede ser cualquiera: autenticación http básica, OpenID, etc.

Nuevos Protocolos y estándares

OpenID OAuth Hybrid Protocol

Como hemos visto, OpenID y OAuth son protocolos con objetivos distintos aunque complementarios: autenticación de usuario (federada) y autorización, respectivamente. El protocolo híbrido OpenID OAuth  combina ambos sistemas, integrándolos en una interfaz única.

Facebook Connect

Debido al enorme incremento de usuarios y, en consecuencia, de datos personales que ha experimentado Facebook en los últimos años, la compañía lanzó en 2008 su propio sistema conocido como Facebook Connect.  Con ese movimiento, Facebook pretendía posicionarse como repositorio central de identidad de los usuarios en Internet. En la actualidad Facebook parece haber  abandonado Facebook Connect para adoptar el protocolo 2.0 de OAuth.

OpenID Connect

El protocolo OpenID Connect es la última propuesta para reactivar OpenID. Su propósito es redefinir y simplificar el protocolo construyéndolo sobre el protocolo OAuth; de ese modo se aprovecha el trabajo desarrollado para OAuth, que parece  estar  extendiéndose rápidamente, dotándolo de una funcionalidad estándar de autenticación que, como hemos visto anteriormente, no posee.

Otros sistemas

Algunos de los grandes proveedores de servicios en Internet han definido, en algún momento, su sistema propio  de autenticación y/o autorización. Sin embargo, la mayoría de ellos están adoptando  estándares  como OpenID y, especialmente, OAuth; es el caso, por ejemplo, de MySpace, Twitter o Yahoo!.

Otro estándar abierto para el intercambio de recursos de identidad es Security Assertion Markup  Language (SAML). Está basado en XML, y su principal propósito es servir de marco para protocolos de autenticación federada. Este protocolo sirve de base para algunos sistemas propietarios de single-sign-on, pero no es utilizado por los grandes proveedores de servicios en Internet.

Resumiendo