Connect; donde OpenID y OAuth se encuentran

Mientras documentaba una breve contribución al Libro Azul de Identificación Digital en el que trabajamos dentro del Cluster de Seguridad de la Red de Cátedras Telefónica, me daba cuenta de que este otoño se alcanzaba un hito interesante en la evolución de las que se pueden considerar las iniciativas más destacadas dentro de los esquemas de autorización delegada e identidad federada que se han popularizado en un escenario repleto de sitios de redes sociales (SRS). Me refiero, respectivamente, a OAuth y a OpenID que, aunque inicialmente surgían como iniciativas separadas y divergentes, han acabado “conectando”.

En septiembre de 2011, la IETF publicaba la versión 2.22 del borrador de OAuth 2.0 para sustituir a la RFC 5849, que estandarizaba en 2010 el OAuth 1.0; mientras que, en octubre de 2011, se publicaba el estándar de OpenID Connect 1.0, que remplazaba el OpenID 2.0 de 2007.

OAuth y su estandarización

La convergencia de OpenID Connect y OAuth 2.0 nos situa, en el momento de escribir estas líneas, en un escenario en el que disponemos de una capa de identidad (OpenID Connect) sobre un protocolo de acceso federado (OAuth 2.0) que permitirá a un sitio web o a una aplicación verificar la identidad de un usuario y obtener cierta información básica de su perfil mediante un proceso delegado y distribuido en la Red. Para entender lo que esto significa puede que resulte interesante repasar brevemente el camino que nos ha llevado hasta aquí.

OpenID fue el primer intento, con cierto nivel de éxito en su adopción, para definir un esquema descentralizado para permitir la identificación en la Web. A pesar de que detrás de la OpenID Foundation están todos los grandes actores de peso en la Red (léase Google, Facebook, Twitter, etc.), lo cierto es que no han conseguido ofrecer un producto “usable”.

Lo que sí consiguió la inicial popularidad de OpenID fue despertar el interés de esos actores ‘emergentes’, como Facebook y Twitter por la identificación como servicio de valor añadido por un usuario que empezaba a mostrarse preocupado por la información personal en poder de los SRS y lo que ello suponía para su “privacidad”.

OAuth se definía como un esquema “centralizado” que permite una autorización delegada para el acceso a una serie de datos del usuario alojados por el proveedor del servicio. OAuth 1.0, elaborado por una comunidad de software libre, acabó en manos de la IETF tras una serie de problemas asociados con la propiedad intelectual de los desarrollos en esa comunidad, siendo estandarizado en la RFC 5849 en 2010.

OAuth 2.0 -adoptado ya por por Google y Microsoft, además de Twitter y Facebook– se apoya en las especificaciones del OAuth Web Resource Authorization Protocol (WRAP) y Simple Web Token (SWT), que salían del grupo de trabajo que la IETF montaba para el desarrollo de este esquema de autenticación.

La evolución de la plataforma de Facebook ha terminado con la adopción de OAuth 2.0 para la autenticación, empujando, además, la evolución de OpenID 2.0 hacia OpenID Connect, un protocolo que utiliza OAuth 2.0 para acceder de forma segura a una API que permita recuperar los atributos del usuario; y que integra lo que se ha denominado OpenID Artifact Binding (AB) para la interacción de aplicaciones en movilidad con servicios en la Web, separando la autorización para el acceso del propio acceso, que se realiza mediante API, pensando en una arquitectura RESTful.

Desde un punto de vista más técnico, cabe destacar aquí, para el lector interesado, el hecho de que OAuth WRAP ha sido mejorado con la inclusión de cierta seguridad a nivel de mensaje, como las firmas; o las ventajas específicas que aporta para un escenario en movilidad, como la posibilidad de generar ‘tokens’ de seguridad para las aplicaciones nativas, evitando el uso de mecanismos como el “password anti-pattern”.

Twitter Digg Delicious Stumbleupon Technorati Facebook Email

No hay comentarios aún... ¡Se el primero en dejar una respuesta!

Dejar un Comentario