En entradas anteriores comentábamos qué era OAuth mediante un ejemplo ilustrativo sencillo, pero es mucho más que eso. Existen distintas configuraciones, escenarios y extensiones que merecen nuestra atención, por la flexibilidad que nos permiten obtener a la hora de implementar un sistema de autenticación y autorización.
En esta entrada vamos a comentaros los dos escenarios que pueden configurarse con OAuth y que nos hace a los desarrolladores la vida un poco más fácil: 
El primer de ellos es el escenario con Acceso Delegado (3-legged scenario), en el cual hay tres actores: Cliente, Propietario del Recurso y Servidor. El Cliente pide acceso a los recursos en nombre de un propietario de un recurso concreto. En este caso las Credenciales que serán necesarias intercambiar para garantizar un mínimo de seguridad son las propietario del recurso y las del cliente. Este escenario es el que ilustrábamos en nuestro anterior post.
El otro escenario que se propone es el que tiene un Acceso Directo ( 2-legged scenario). Los actores en este escenario son sólo dos: Cliente y Servidor. Esta situación se da cuando el Cliente pide acceso a los recursos en su nombre. En este caso el Cliente y el Propietario del Recurso serán la misma entidad y sólo será necesario enviar las Credenciales del Cliente.
OAuth (Open Authorization; Autorización abierta) es un estándar abierto que permite incluir seguridad en la autenticación para aplicaciones web y de escritorio.
Su origen se remonta a la necesidad de querer establecer un protocolo estándar que sacara factor común de las buenas prácticas existentes en los distintos sistemas de autenticación existentes, como por ejemplo Google AuthSub , AOL OpenAuth , Flickr API y Amazon Web Services API entre otras.
Para ilustrar las ventajas de OAuth, veamos el siguiente ejemplo: Una aplicación nueva incluye un servicio de avisos de fechas importantes que deberá importar de otra aplicación, por ejemplo, la agenda del gestor de correo. Para poder activar el servicio es necesario que el sujeto en cuestión le de su nombre de usuario y contraseña para así acceder al gestor de correo. El resultado obtenido es que ambas aplicaciones funcionan correctamente, pero existe un inconveniente primordial: la aplicación que da el servicio de avisos ya tiene su contraseña, lo cual puede llevar a un problema de seguridad grave.
OAuth intenta solucionar esta problemática restringiendo el acceso a los recursos. En el ejemplo anterior, mediante OAuth se habría conseguido que la aplicación servidora sólo pudiera acceder a la información del calendario, evitando así tener que darle el nombre de usuario y contraseña y que hubiera un acceso ilimitado a la información contenida en el gestor de correo.
En vez de utilizar nombre de usuario y contraseña, OAuth utilizará unas credenciales que permitirán el acceso a uno o varios recursos por un periodo de tiempo determinado.
Inteco organiza junto a la Dirección General de la Sociedad de la Información y Medios de Comunicación de la Unión Europea la Conferencia sobre Confianza en la Sociedad de la Información (Trust in the Information Society), que tendrá lugar en León el 10 y 11 de febrero.
Este evento incluye las siguientes temáticas:
- Servicios en red y entornos informáticos de confianza
- Un marco europeo común para gestión de identidades
- Desarrollo de tecnologías y marco legal de la Unión Europea para protección de datos y privacidad
- Cooperación internacional sobre confianza y la investigación sobre seguridad
Más información: http://trustworthyict.inteco.es
Al desarrollar aplicaciones con OAuth nos surge la duda de cuál librería de las que existen nos conviene más utilizar.
En el caso de que queráis programar en PHP hay varias opciones. A continuación comentamos cada una de ellas,
teniendo en cuenta los principales aspectos que interesan en OAuth como pueden ser qué versión soporta, si es genérica o es la extensión de un framework concreto o si contiene funciones para implementar un proveedor de servicio.
- Autor: John Jawed
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: SI
- ¿Hay Documentación?: SI
- Autor: Andy Smith
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: SI
- Versión de OAuth Soportada: 1.0
- ¿Genérica?: SI
- ¿Hay Documentación?: SI
- Autor: Cal Henderson
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: SI
- ¿Hay Documentación?: Escasa
- Autores: Jeff Hodsdon y Bill Shupp
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: SI
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: SI
- ¿Hay Documentación?: SI
- Autor: Daniel Hofstetter
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: No, es para CakePHP
- ¿Hay Documentación?: Escasa
- Autor: Justin Richer
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: NO
- Versión de OAuth Soportada: 1.0
- ¿Genérica?: No, es para Elgg
- ¿Hay Documentación?: Escasa
- Autor: Pádraic Brady
- ¿Implementa Consumidor?: SI
- ¿Implementa Proveedor de Servicio?: SI
- Versión de OAuth Soportada: 1.0a
- ¿Genérica?: No, es para Zend
- ¿Hay Documentación?: SI