OAuth 2.0: Habilitando identidad para la nube y las aplicaciones móviles
05 March, 2014
category: Seguridad en Internet, Seguridad lógica
La identidad digital gana cada vez más en importancia a medida que las empresas se esfuerzan por proteger y controlar el acceso a los recursos en línea. Se desarrollan una serie de estándares que contribuyen a que la gestión de identidad y el inicio de sesión único (single sign-on) se hagan realidad para las organizaciones que implementan sistemas.
Al concluir 2013, SecureIDNews.com consideró cuatro diferentes estándares de identidad, y el rol que estos juegan en el apoyo a las empresas para la creación de ecosistemas de identidad.
Los principales pilares técnicos de la nube – y de la emergente Internet de los Objetos – son las API. Conocidas también como Interfaces de Programación de Aplicaciones, las API proveen métodos consistentes para entidades externas, tales como clientes de servidor y aplicaciones móviles, con el fin de interactuar con servicios y datos en la nube de una forma limpia y estandarizada.
Las API dejan a un lado la complejidad subyacente de la aplicación, permitiendo que los clientes externos puedan disponer de un conjunto bien definido de posibles solicitudes y respuestas. Debido a las ventajas que ofrecen para crear arquitecturas disponibles y escalables, las API se utilizan más para mover datos, por el contrario de las aplicaciones de navegador.
Sin embargo, no fue hasta fecha reciente que la seguridad y escalabilidad de las API se vio amenazada por un modelo de autenticación y autorización denominado a veces “anti-patrón de contraseña”, un método en el que los clientes que quieren llamar una API a nombre de un usuario en particular, obtienen y reingresan la contraseña para ese usuario cuando se llama a la API. Este modelo de autenticación es caracterizado como un anti-patrón porque por una parte se basa inadecuadamente en contraseñas que son compartidas fuera del propio contexto, y por otra parte no es capaz de dar soporte a la adecuada granularidad de permisos y revocación.
OAuth 2.0 ofrece una alternativa a ese anti-patrón de contraseña, definiendo una autenticación, autorización y arquitectura de política consistentes y flexibles para los servidores web, las aplicaciones y dispositivos móviles que tratan de comunicarse con las API de nube.
OAuth 2.0 define un esquema para asegurar el acceso de la aplicación a recursos protegidos – que suelen ser, aunque no únicamente, atributos de identidad de un usuario en particular – a través de APIs, en su mayoría típicamente RESTful. REST define un conjunto de principios de arquitectura, mediante los cuales los usuarios pueden diseñar servicios web que se enfocan hacia recursos de un sistema, incluyendo cómo se dirigen y transfieren estados de recurso mediante HTTP de clientes que escriben en diferentes idiomas.
Hay tres participantes primarios en el flujo OAuth. Primeramente OAuth permite que un cliente – una aplicación que desea información – envíe una consulta API a un Servidor de Recursos, la aplicación que aloja la información deseada, de modo que el servidor pueda verificar que el mensaje realmente ha sido enviado por un cliente válido.
El cliente autentica entonces al Servidor de Recursos a través de la inclusión de un token de acceso en su mensaje API, un token previamente suministrado al cliente por un Servidor de Autorización.
En esos escenarios OAuth, en los que la API en cuestión protege el acceso a atributos de identidad de un usuario, puede ocurrir que el token de acceso sea emitido por el Servidor de Autorización solo después que el usuario ha dado consentimiento explícito para que el cliente acceda a esos atributos.
OAuth ofrece significativas ventajas en comparación con el anti-patrón de contraseña. En primer lugar, al tener que presentarse por el cliente un token que represente al usuario y su consentimiento para una interacción API dada, en lugar de utilizar solamente la contraseña del usuario, el cliente realmente no necesita ver la contraseña.
Considere, por ejemplo, el termostato ‘Nest’ habilitado para Internet. Aunque puede ser aceptable que la propia aplicación Android de Nest sea la que autentifique sus llamadas API a los servidores de Nest mediante la inclusión de la contraseña Nest del usuario – a través de la cual el termostato puede controlarse, consultarse, etc. – no sería apropiado que una aplicación de tercera parte hiciera lo mismo. En lugar de eso, para la aplicación de tercera parte se emitiría un token de acceso que puede tener privilegios reducidos, por ejemplo: leer pero no escribir, y puede revocarse cuando se desee.
Las arquitecturas API de gran escala para la nube, los móviles y para Internet de los Objetos sencillamente no son viables sin un modelo de autenticación y autorización que pueda escalar en correspondencia. Es decir, que OAuth 2.0 define ese tipo de estructura y va a ser un elemento crítico para el desarrollo y avance del conjunto de herramientas de seguridad de la API.