Hace ya unos meses Guillermo nos informaba de que Twitter pasaría a permitir el acceso a la API únicamente a través de OAuth. En el momento se suponía que esto iba a ocurrir a partir de finales de junio, pero finalmente fue ayer cuando este nuevo requisito pasó a convertirse en obligatorio.

Hasta ahora existían dos formas de permitir el acceso de una aplicación a nuestro perfil de Twitter, la clásica en la que tenemos que entregar nuestra contraseña y OAuth, en la que no es necesario.

Así que a partir de ahora ya no tendremos que escribir más nuestra contraseña, con lo mejora la seguridad para los usuarios y para los creadores de las aplicaciones, que no se tienen que encargar de almacenarlas. Simplemente tendremos que identificarnos y “aprobar” o “denegar” el acceso de una aplicación determinada a nuestro perfil.

Lo bueno de todo esto es que además podemos ver en todo momento qué aplicaciones están teniendo acceso. En la configuración de cada perfil, bajo la pestaña de Conexiones podréis ver la lista y eliminarlas en cualquier momento.

Suponemos que ahora pueden aparecer problemas con algunas aplicaciones, aquellas que no hayan actualizado sus versiones todavía y que utilizasen hasta ahora el antiguo sistema de identificación. Por eso, atentos porque seguro que en las próximas horas se producen muchas actualizaciones, y ya se sabe que algunos dan gato por liebre.

Lo que está claro es que la seguridad de Twitter se ve mejorada con la implantación de OAuth y su obligatoriedad. Eso no quiere decir que vaya a ser infalible y no tengamos casos de problemas con contraseñas y demás; aunque mucho de eso está relacionado con la tendencia a hacer click, click, click.

Vía | Twitter Blog
En Genbeta | Twitter sólo permitirá acceso a la API a través de OAuth
Imagen | Adam Jackson

Podemos sincronizar todo lo que compartamos, sólo los compartidos que tengan notas (ya sea usando “compartir con nota” o el bookmarklet “Nota en Reader”) o solamente las notas. También podemos personalizar el formato de los tweets con los parámetros de título {title}, dirección {url} y nota {comment}, además de lo que añadamos nosotros (el típico “Interesante” o “Desde mi Reader”).

El servicio hace uso del protocolo pubsubhubbub, de manera que supuestamente la sincronización es en tiempo real, aunque al probarlo, he notado un cierto retraso de minutos. Claro que, dado como anda Twitter últimamente, no se puede pedir mucha exactitud en estas cosas. Dejando esto a un lado, el servicio cumple con la pequeña tarea que ofrece y es sencillo de usar.

Vía | Feedmyapp
Enlace | Reader2Twitter

Tenemos nuevo protocolo en Internet. Se llama Messenger Connect, y su función es que los desarrolladores web puedan integrar Windows Live Messenger y su red en sus aplicaciones. Y no, el parecido con el nombre de Facebook Connect no es coincidencia, es que el propósito es prácticamente el mismo.

Messenger Connect es un conglomerado de las APIs ya existentes para esta red, más unas pocas novedades. Con este protocolo nos podremos identificar en las webs con nuestra ID de Windows Live, y éstas podrán acceder a nuestro círculo social en la red de Windows Live, además del chat en Windows Live Messenger. Desde Microsoft también prometen que su implementación será sencilla para los desarrolladores.

El planteamiento es, como veis, muy similar a Facebook Connect y Twitter OAuth. Al igual que en estos, también deberemos dar nuestro permiso para que la aplicación acceda a nuestra cuenta, y podremos revocar éste en cualquier momento. Además, también estará basado en protocolos estándar, como OAuth, recientemente adoptado por Facebook .

De momento, Messenger Connect sólo esta disponible en pruebas para un número reducido de webs, pero esperan poder ampliarlo pronto para todo el público, abriendo más si cabe la integración de todos nuestros servicios y llevando nuestro perfil web por allá donde vayamos.

Más información | Inside Windows Live
En Genbeta | Windows Live Messenger para el iPhone al descubierto

Seguro que todos conocéis por lo menos una aplicación que se conecta a vuestro Twitter, ya sea un cliente de escritorio, un acortador de URLs o una herramienta para gestionar tus amigos en la red. Todas estas aplicaciones usan la API de Twitter, y para entrar con vuestro usuario necesitan o bien vuestra contraseña o bien una autorización por OAuth.

Pues esto va a cambiar. El día 30 de junio, dentro de nueve semanas, Twitter sólo permitirá la autenticación en la API por medio de OAuth. Un gran avance en seguridad tanto para usuarios como para los desarrolladores, porque ni unos tendrán que preocuparse quién y de qué manera guarda sus contraseñas, ni los otros tendrán que buscar soluciones seguras para almacenarlas. Además, cuentan con la ventaja de que OAuth es un protocolo abierto, usado por un buen número de servicios incluyendo GMail y próximamente Facebook, tal y como os anunciamos en Genbeta.

Un buen movimiento por parte de Twitter, que nos beneficiará a todos, usuarios y desarrolladores, no sólo en cuanto a seguridad, sino también en cuanto a comodidad y unificación de este tipo de protocolos.

Vía | Mashable
Más información | Twitter API Group
Enlace | Countdown to OAuth
En Genbeta | XAuth: nuevo intento del resto de redes sociales de luchar con Facebook

Durante la conferencia que Facebook ha ofrecido hoy (el F8), Mark Zuckerberg CEO de la compañía ha anunciado que Facebook Connect será sustituida por el lanzamiento de una nueva forma de conectarse llamado Open Graph. Así la compañía apuesta por la estandarización y por la interacción de Facebook usando el protocolo OAuth 2.0 y su integración en Open Graph.

De esta forma Facebook contraataca a alternativas recientes como XAuth, puesto que Open Graph tendrá una API que permitirá a los desarrolladores un mayor acceso y más facilidades para integrar los servicios de Facebook en sus sitios web. Además cuentan con apoyos de Yelp, Pandora o el mismo Microsoft, o sea que juegan sobre seguro.

Lo que todavía no queda claro es cómo se va a hacer la transición, o incluso no quedó claro si se iban a pensar cambiar el nombre al servicio Facebook Connect por otro distinto. Así pues ya véis como queda el panorama, los demás aprietan y Facebook se renueva, lo que es seguro es que a los usuarios siempre nos va comportar mejoras ya que la evolución de las conexiones y la mayor simplicidad en las tareas de autentificación siempre es bienvenida.

Vía | FaceBook blog
Más información | Mashable

A muchos os sonará el nombre OAuth: Es el protocolo que usa Twitter para ofrecer un modo rápido de identificarse en algunos servicios y otras redes sociales. Es uno de los competidores directos de Facebook connect. Google, ante esto, no se ha quedado de brazos cruzados y ha empezado a integrar OAuth en sus cuentas IMAP de GMail.

Hasta ahora Google ofrecía un servicio parecido con el que introduciendo la contraseña de su cuenta podíamos autorizar a otras páginas web usar ciertos datos de nuestro correo. Pero con OAuth integrado no necesitaremos ni siquiera escribir nuestras contraseñas siempre que tengamos una sesión iniciada en GMail, manteniendo el nivel de seguridad.

La funcionalidad empezará a estar presente de forma gradual en algunos servicios, empezando por Syphir (un gestor de notificaciones push en el iPhone de Apple cuyas capturas podéis ver en la imagen superior), que no necesitará guardar nuestra contraseña de Google en sus datos para poder funcionar. Según Google, el objetivo es conseguir un estándar para poder usar Auth con las cuentas de correo IMAP, y que todas las aplicaciones que gestionen nuestros correos sean capaces de usar este estándar.

Vía | Google Code
Sitio oficial | Gmail
En Genbeta | Gmail te alerta cuando tu cuenta puede haber sido comprometida

Los formularios de identificación en las páginas web están experimentando una evolución gracias a las APIS como OAuth, que permiten que nos conectemos a cualquier página web usando nuestros datos de otras redes sociales. La más popular de estas identificaciones es la que ha implementado Facebook, llamada Facebook Connect.

Twitter, que también tiene un servicio similar, quiere contrarrestar el éxito de las credenciales de Facebook aplicando ciertas mejoras a su sistema, según han afirmado varias fuentes. La conexión con los datos de Twitter se caracteriza por su sencillez, pero quiere facilitar el trabajo de los administradores web a la hora de implementar sus comentarios en la web.

La ventaja que tiene Twitter es que usa protocolos abiertos, mientras que Facebook usa un sistema cerrado. A partir de ahí, Twitter puede mejorar más libremente su sistema para integrar, por ejemplo, la identificación de Twitter en cualquier blog, de modo que poco a poco nos iríamos librando de tener que introducir nuestros datos en cada sitio donde queramos publicar comentarios.

Vía | TechCrunch
En Genbeta | Twitter quiere vitaminar su API para ofrecer un mejor servicio a las aplicaciones de terceros

De cara al servicio web
Para aquellos que estén desarrollando servicios web, deben comenzar a tener muy en cuenta a oAuth. oAuth es el proceso que están implantando las empresas nombradas con el fin de integrar los contenidos de los usuarios, portando todos sus datos, en otros servicios basándose en una identificación cruzada, pero manteniendo como origen el servicio web original.

Por ejemplo, si nos identificamos con Google (registro de nuestro usuario), a partir de ahora podríamos entrar en Zoho sin la necesidad de identificarnos de nuevo, ya que el propio Google ID haría tal función. A su vez, podría portar nuestros contactos de Gmail y nuestros documentos de Google Docs a las aplicaciones respectivas en Zoho.

Del mismo modo sucede con Data Availability, promovido por MySpace, por el que los usuarios de MySpace podrían migrar sus datos a otras redes como Twitter, eBay o Yahoo!, sin la necesidad de volver a introducirlos, o incluso aportando nuevos contenidos disponibles a través de la colaboración (suponiendo, mostrar nuestras canciones publicadas en MySpace en la barra lateral de nuestro usuario de Twitter).

El movimiento de ficha por parte de Google es Google Friend Connect, que nos permite crear widgets donde los usuarios puedan identificarse con el usuario de otras redes diversificando los sistemas, descentralizando todavía más la autenticación que con OpenID, y permitiendo, a su vez, importar datos desde las mismas como han estado realizando Facebook con su Facebook Connect (proceso similar al de MySpace).

De cara al usuario
El usuario, a partir de ahora y según se incrementen este tipo de implementaciones, verá como con su usuario de la aplicación web X podrá migrar a otras aplicaciones, portar sus datos, mover a sus contactos de una red social a otra, etc. con un simple clic, del mismo y sencillo modo con el que damos acceso a nuestras imágenes con Flickr. Un simple clic.

Ahora bien, también tenemos que pensar en cómo afecta esto a OpenID ya que si el registro de usuario se delega a este modelo, únicamente deberemos hacerlo en una red, por ejemplo con nuestro usuario de Google, y con él, identificarnos en otras redes ya sea a través de Google Friend Connect o con el acceso vía oAuth de un servicio web a nuestra cuenta, con lo que se estaría degradando en parte a OpenID como sistema de identificación. OpenID podría no ser ya necesario.

Si el modelo es el de utilizar oAuth como sistema de identificación (por el momento, sólo ejecutado por Zoho) a partir de nuestros actuales perfiles de usuario, se estaría optando más por un modelo similar al promovido por Microsoft con su Windows Live ID, .Net Passport en su época, pero de modo descentralizado (más cercano a éste que a OpenID).

La tendencia generalizada, por suerte, dista bastante de la acción de Zoho optando por una identificación con OpenID y la importación de datos vía oAuth, aunque la widgetización que plantea Google no termino de ubicarla como solución para desarrollos más allá de un usuario de Blogger.

A título personal, los widgets (OpenSocial, Facebook Apps,...) son a la Web 2.0 lo que los GIFs animados fueron a la Web 1.0.

La estructura original que permitirá implementar este concepto está compuesta de:

• OPML, formato de importación/exportación agrupada de conjuntos de feeds RSS/ATOM, a priori.
• APML, con la esencia del OPML pero categorizando, etiquetando y valorando según el grado de interés (grado de atención) sobre los feeds en cuestión.
• hCard, microformato que implementa una versión web de la vCard y que permite exportar nuestra tarjeta de visita de un modo sencillo.
• OpenID, a través de una URL podremos identificarnos y nuestros datos serán importados en el caso de demos acceso al sitio web cliente de OpenID.
• OAuth, similar al OpenID, pero limitando su gestión a una URL única sin necesidad de estar identificados en el servidor que nos da el servicio.
• RDF y RSS, para la sindicación de contenidos.
• XFN, otro microformato para establecer la relación con nuestras URLs y con las URLs de nuestros contactos.

Parece, desde lejos, que es otro estándar más que no tendrá mucha importancia, pero si nos acercamos un poco más veremos que DataPortability será uno de los pilares, si no el más importante, de lo que algún día se le podrá llamar Web 3.0 (o el nombre que se le quiera dar).

De momento, sin que sirva de precedente, ya han dado su apoyo (lo cual no compromete a llevar nada a cabo) Google, Facebook, LinkedIn, Plaxo, Drupal, Netvibes, Mystrands, Flickr, SixApart y Twitter, entre otros. Ahí es nada…

De momento, los RSS y los OPML ha se han hecho un hueco en nuestras vidas y OpenID lo está empezando, sobre todo gracias a que se están implementando infinidad de clientes como los comentarios en Blogger y algunos nuevos servidores como el de AOL o el futuro servidor de OpenID de Yahoo!.

Enlace | DataPortability.
Más info | Wikipedia.