Autentificación Segura con OpenID

OpenID es un sistema de identificacion digital, descentralizado que nos permite ingresar a multiples sitios web que soportan el protocolo como nuestro Portal Insecure, con una sola cuenta.

A diferencia de arquitecturas Single Sign-On, OpenID no especifica el mecanismo de autenticación. Por lo tanto, la seguridad de una conexión OpenID depende de la confianza que tenga el cliente OpenID en el proveedor de identidad. Si no existe confianza en el proveedor, la autenticación no será adecuada para servicios bancarios o transacciones de comercio electrónico, sin embargo el proveedor de identidad puede usar autenticación fuerte pudiendo ser usada para dichos fines.

en mi caso personal he encontrado muchos proveedores de identidad sobre OpenID, pero preferi usar Verising por la seguridad que me da su servicio, que por lo demas es como la gran mayoria Gratuito!

pude ademas verificar que es muy economico agregar un segundo factor de autentificacion de OpenID con unos Tokens que vende Verising desde U$30 hasta los U$48 en el caso que quieran la Tarjeta de Seguridad VIP. aunque si poseen un softphone puedes usar la version de Software que es GRATIS, pero debes pagar por los SMS enviados en cada proceso de Autentificacion, por lo que puede terminar saliendo mas caro en el largo plazo dependiendo de cuanto uso le des a OpenID.

Como Funciona

Un sitio web, como ejemplo.com, que quiere ofrecer acceso a sus visitantes a través de OpenID, coloca un formulario de identificación en alguna de sus páginas. Al contrario que los típicos formularios de identificación que preguntan al usuario por su nombre y contraseña, en este caso sólo existe un campo para el identificador OpenID. El sitio web puede optar por mostrar un pequeño logo OpenID junto al campo. Este formulario estará conectado a una implementación de la biblioteca cliente OpenID.

Si, por ejemplo, Alicia quiere acceder a ejemplo.com usando el identificador OpenID alicia.proveedor-openid.org que ella previamente ha registrado en el proveedor de identidad proveedor-openid.org, simplemente va a ejemplo.com y teclea alicia.proveedor-openid.org en la caja de identificación de OpenID. A partir de la versión 2.0 de la autenticación OpenID (y en algunas de las implementaciones de OpenID 1.1) Alicia también puede identificarse tecleando un i-nombre como =ejemplo.alicia o =ejemplo.comunidad*alicia.

Si el identificador es una URL, la primera cosa que debe realizar la parte (ejemplo.com) es transformarla a una forma canónica, del tipo http://alicia.proveedor-openid.org/. Con OpenID 1.0, la parte confidente solicita entonces la página web situada en dicha URL y, vía una etiqueta HTML de enlace, descubre que el servidor del proveedor es, pongamos, http://proveedor-openid.org/openid-auth.php. También descubre si debe o no usar una identidad delegada (ver más abajo). A partir de OpenID 1.1, el cliente realiza el descubrimiento de estos datos solicitando el 'documento XRDS (también llamado documento Yadis) con el tipo de contenido application/xrds+xml, que puede estar disponible en dicha URL y que siempre estará disponible a través de una XRI.

Hay dos modos mediante los cuales la parte confidente puede comunicarse con el proveedor de identidad:

checkid_immediate, el cual está orientado a la identificación automática y en el que toda comunicación entre los dos servidores se realiza como una tarea de fondo, sin que el usuario sea consciente de ello;
checkid_setup, en el que el usuario se comunica directamente con el servidor proveedor usando el mismo navegador web que emplea para acceder al sitio de la parte confidente.
La segunda opción es más popular en la Web; también puede suceder que un checkid_immediate termine convirtiéndose en un checkid_setup si la operación no puede automatizarse.

En primer lugar, la parte confidente y el proveedor (opcionalmente) establecen un secreto compartido, que la parte confidente se encarga de almacenar. Si se emplea checkid_setup, la parte confidente redirige el navegador web del usuario hacia el proveedor. En el ejemplo, el navegador de Alicia sería redirigido a proveedor-openid.org de manera que Alicia pudiera autenticarse contra el proveedor.

El método de autenticación puede variar, pero normalmente un proveedor OpenID pide una contraseña (y entonces posiblemente almacena la sesión del usuario usando cookies, tal y como hacen muchos sitios con autenticación basada en contraseña). En caso de que Alicia no tenga una sesión activa en proveedor-openid.org, este le solicitará su contraseña. Una vez tenga la sesión abierta el servidor la preguntará acerca de la confianza que le ofrece http://ejemplo.com/openid-retorno.php (la página designada por ejemplo.com como destino al que el usuario debería volver tras completar la autenticación para recibir los detalles de su identidad). Si ella responde positivamente, la autenticación OpenID se considera exitosa y el navegador es redirigido a la página de retorno indicada con las credenciales otorgadas. Si Alicia decide no fiarse del sitio de la parte confidente, el navegador también será redirigido, pero se notificará del rechazo a la parte confidente, de manera que ejemplo.com como contrapartida se negará a autenticar a Alicia.

Sin embargo, el proceso de login no ha terminado todavía porque en esta etapa, ejemplo.com no puede decidir si las credenciales recibidas realmente fueron recibidas desde proveedor-openid.org. Si ellos habían establecido previamente un secreto compartido, el consumidor puede validar el secreto compartido recibido con las credenciales que tuviese guardadas previamente. Cada consumidor es llamado con estado porque guarda el secreto compartido entre sesiones. En comparación, un consumidor sin estado o mudo deberá hacer una petición más a fondo (check_authentication) para asegurarse que los datos vinieron de verdad de proveedor-openid.org.

Después de que el identificador de Alicia haya sido verificado, ella será considerada registrada en ejemplo.com como alicia.proveedor-openid.org. El sitio puede entonces guardar la sesión o, si este es su primer registro, pedir a Alicia que introduzca información específica para ejemplo.com para terminar el registro. (Fuente: Wikipedia)
 

Bueno aprovecho de indicarles algunos proveedores de OpenID para que prueben como les va, en general me ha funcionando perfecto y no he tenido ningun problema. En el caso que elijan Verising, les recomiendo que usen Beatbelt for firefox, pues permite detectar de forma automatica sitios que funcionan con el protocolo OpenID e ingresar automaticamente.

https://pip.verisignlabs.com/

http://confirma.org/_/?idio=es

http://openid.es/