OpenID y OAuth

Hasta el momento, la autenticación y la autorización se hacia directamente contra el servidor que alojaba la pagina web que el usuario necesitaba. Este representaba una amenaza a la seguridad de nuestros datos, ya que si un intruso informático llegaba a atacar dicho servidor, podría llevarse toda la información personal que tuviéramos almacenada en este. 

Afortunadamente se han estado investigando unos estándares de autenticación y autorización, que en síntesis se convertirían en un proceso de tres vías, ya que los agentes que intervienen en en son: el usuario, el servidor que contiene la aplicación (consumer), y el proveedor de autenticación y autorización (provider). Este esquema funciona así:

1. El usuario pide autenticarse contra el servidor de la app web.

2. El servidor web pide verificación de identidad del usuario contra el provider.

3. El provider pide verificación de identidad al usuario.

4. El usuario confirma su identidad contra el provider. (Generalmente es un clic).

5. El provider genera un Token de confirmación de identidad del usuario y se lo envia al servidor web.

6. El servidor web almacena el Token, y le permite el acceso al usuario.

En este esquema, el usuario no tendrá que generar un usuario y una contraseña para cada servicio que utilice, si no que or el contrario usara un solo token generado por los providers. En este momento hay tres providers "reconocidos": 

* Google

* Facebook

* OpenID (Por ser los creadores de este estándar).

Este estándar tiene sus ventajas y sus desventajas:

* La principal ventaja es que el usuario no tendrá que recordar varias contraseñas, y que ademas tendrá la seguridad de que su provider sera virtualmente imposible de vulnerar.

* La principal desventaja es que si el provider genera el token sin tiempo de vida (Que se pueda utilizar eternamente), y el consumer llega a ser vulnerado, se podría tener acceso a todas las cuentas del usuario.

OpenID

El sistema OpenID fue desarrollado originalmente por Brad Fitzpatrick de LiveJournal, aunque David Recordon de VeriSign, Josh Hoyt de JanRain y Dick Hardt de Sxip son ahora co-autores. Las futuras especificaciones de OpenID serán desarrolladas en una meritocracia basadas en la lista de distribución. Para apoyar la implantación de OpenID, un grupo de empresas anunció en agosto de 2006 un programa de contribuciones de desarrollo, ofreciendo 5000$ a los primeros diez proyectos de software libre que implemente total compatibilidad con OpenID.

A partir de la versión 1.1, OpenID utiliza el protocolo de búsqueda de servicios Yadis. En diciembre de 2007 vio la luz la versión 2.0 de la Autenticación OpenID³ 

La Fundación OpenID (en los Estados Unidos), así como su filial OpenID Europe, se crearon en 2007. Es una organización sin ánimo de lucro cuyo papel es la organización y el desarrollo del framework OpenID para la comunidad, así como administrar su propiedad intelectual.

A partir de la versión 2.0 de la autenticación OpenID (y en algunas de las implementaciones de OpenID 1.1), hay dos tipos de identificadores: URLs y XRIs.

Identificadores OpenID.

URLs

Hay dos formas de obtener una URL OpenId valida que pueda ser usada para registrarse en todos los sitios que soporten OpenID.

1. Primero, usar una URL existente que tu controles (como tu blog o página personal), y si sabes editar HTML podrás insertar los tags OpenID apropiados en el código siguiendo las instrucciones de las especificaciones de OpenID. Comentar que usando un subdominio podrás hacer que tu OpenID sea más fácil de escribir, pero no es necesario.
2. Segundo, registrar tu identificador OpenID con un proveedor de identidades. Estos ofrecen la posibilidad de registrar URLs (habitualmente terceros niveles de dominio) configuradas automáticamente para ser utilizadas con servicios de autenticación OpenID.

XRIs

Los XRIs son un nuevo sistema de identificación en nternet, diseñado específicamente para identidades digitales de dominio cruzado. Los XRIs son de dos formas i-nombres e i-numeros que son habitualmente registrados simultáneamente como equivalentes. Los I-nombres son reasignables (parecidos a nombres de dominio), mientras que los i-números nunca son reasignados. Cuando un i-nombre XRI es usado como un identificador OpenID, este es resuelto inmediatamente por el i-número equivalente (el elemento CanonicalID de un documento XRDS). Este i-número es el identificador OpenID almacenado por la parte confidente. De esta manera el usuario y la parte confidente están protegidos contra los cambios de identidad que podrían suceder con una URL basada en un nombre DNS reasignable.

OpenID ha recibido numerosas críticas de base relativas a problemas desde distintos ámbitos, pero en especial de seguridad y privacidad. La unificación de todas las identidades conlleva altos riesgos, unido a que el servidor de identidad conocerá todas las webs que se visiten cada día. Es más, si se comprometiera la seguridad del ordenador usuario o del servidor, toda la vida digital del usuario quedaría desprotegida.

http://openid.net/

http://es.wikipedia.org/wiki/OpenID

OAuth

Es un protocolo abierto, propuesto por Blaine Cook y Chris Messina, que permite autorización segura de un API de modo estándar y simple para aplicaciones de escritorio, móviles, y web.

Para desarrolladores de consumidores, OAuth es un método de interactuar con y publicar datos protegidos. Para desarrolladores de proveedores de servicio, OAuth proporciona a los usuarios un acceso a sus datos al mismo tiempo que protege las credenciales de su cuenta. En otras palabras, OAuth permite a un usuario del sitio A compartir su información en el sitio A (proveedor de servicio) con el sitio B (llamado consumidor) sin compartir toda su identidad.

OAuth comenzó en noviembre de 2006, cuando Blaine Cook desarrollaba la implementación de OpenID para twitter. Mientras tanto, Ma.gnolia necesitaba una solución que permitiera a sus miembros con OpenID a autorizar widgets del dashboard para acceder a su servicio. Entonces, Cook, Chris Messina y Larry Halff de Ma.gnolia se reunieron con David Recordon para discutir el uso de OpenID con las APIs de Twitter y Ma.gnolia para delegar la autenticación. Llegaron a la conclusión de que no existía ningún estándar abierto para delegar acceso a las APIs.

En abril de 2007 se creó el grupo de discusión de OAuth, para que el pequeño grupo de implementadores escribiera un borrador de propuesta para un protocolo abierto. DeWitt Clinton de Google se enteró del proyecto OAuth y se mostró interesado en apoyar el esfuerzo. El equipo terminó el borrador inicial de la especificación en julio de 2007. Eran Hammer-Lahav se unió y coordinó las diversas contribuciones a OAuth, creando una especificación más formal. El borrador definitivo Oauth Core 1.0 se publicó el 3 de Octubre de 2007.

http://oauth.net/

http://es.wikipedia.org/wiki/OAuth