OAuth 2.0, autorizando el uso de recursos

OAuth 2.0 tal y como se define en el RFC 6749 es aquél framework de autorización que permite a la aplicación de un tercero obtener un acceso limitado a un cierto servicio http, lo que comúnmente llamamos un API.

El framework de autorización OAuth, establece un conjunto de roles entre los que se deben orquestar los procesos necesarios para establecer si finalmente un cliente tiene los permisos para acceder a un recurso.

Los roles definidos son el cliente que consume un recurso, el servidor donde se halla este recurso, el dueño del recurso que va a ser consumido y aquel servidor que autoriza el consumo del recurso.

Roles en OAuth

En un ejemplo típico, el cliente podría ser aquella web a la que accedo y en lugar de crear una nueva cuenta me permite usar mi credencial de Facebook. El servidor del recurso puede ser Facebook también. El dueño del recurso sería yo mismo.  Y por último el servidor de autorización sería el de facebook.com.

¿Cómo se establece el diálogo entre los distintos actores para finalmente autorizar el uso a un cierto cliente?

La web a la que accedo va a pedir al dueño del recurso, en el ejemplo sería yo mismo, autorización para usar la información. En este paso normalmente se determina el nivel de autorización, si sólo voy a permitir el acceso en mi nombre, o si permito que se acceda a más información de mi perfil. Si concedo permiso a utilizar mis credenciales, al final la aplicación cliente va a presentar un token de acceso al servidor del recurso para que pueda acceder a esta novedosa web.

Es importante notar la presencia de un token de autorización, este token puede ser almacenado por la aplicación cliente y ahorrar al usuario final ( que podría ser una aplicación ) de tener que hacer login cada vez que quiera acceder ( usaría el login de facebook. Simplificamos el proceso de registro, a cambio de hacer concesiones a un tercero.

La era de las APIs públicas

Después de describir las Web APIs en mi anterior post, deje pendiente por analizar distintas visiones que están teniendo lugar en el espacio de las APIs, principalmente en la dicotomía APIs publicas / APIs privadas.

Definía un Web API, no solo cómo el conjunto de funciones y procedimientos que permiten manejar los objetos de negocio, sino además todos aquellos otros elementos alrededor del API en sí misma que permiten su gobierno, el control de los accesos y la seguridad en sí misma sobre dichas funciones y procedimientos.

Por extensión de un Web API, un Web API pública es aquella Web API que expone los objetos de negocio a la comunidad de desarrolladores de internet, es decir, potencialmente a toda la comunidad de desarrolladores.

Habitualmente es necesaria una gestión de esta comunidad de desarrolladores de forma que se tenga un gobierno de los diferentes desarrolladores, así como las apps o mashups que desarrollan, en definitiva de los clientes de nuestra API pública. De esta forma podemos saber cuáles son los usos más comunes, y así progresar el desarrollo de nuevas versiones teniendo en consideración esos usos.

Una API pública puede ser usada por cualquiera para acceder a los métodos de los objetos internos de negocio, solo debe tener un token de identificación de desarrollador, lo cual dependiendo del negocio en sí mismo puede crear un conflicto, ya que como veremos a continuación lo genial de las Web APIs, permitir que unos sitios web usen recursos de otros y ambos crezcan juntos, también ha desembocado en algunos desencuentros.

Twitter tuvo que cambiar su API pública para que la existencia de aplicaciones de terceros no afectasen a su modelo de negocio.

Netflix ha anunciado que va a retirar su API pública, y solamente un conjunto de desarrolladores que realmente estén aportando valor a su negocio van a tener acceso a la nueva versión del API, que será privada. Veremos más sobre APIs privadas en un próximo post.

Aunque aparentemente podría parecer que exponer un API pública podría ser sólo fuente de desencuentros, es también una gran fuente de ventajas. Es el caso de American Express, que expone un API pública para la realización de pagos con puntos de su programa de fidelización (Amex Points), un uso insospechado para American Express de esta API era la posibilidad de pagar con Amex Points en la archiconocida Uber con el incremento en el número potencial de pagos a través de este API pública.

La discusión es si las APIs públicas están en vías de desaparecer, y estamos en el fin de una era, o si se impone un cambio de modelo. Seguiré ahondando en esto en el próximo post.