OAUTH 2.0 es un mecanismo de autorización -no de autenticación-, que detalla cómo gestionar un acceso delegado a diferentes aplicaciones (web, nativas o móviles), y dispositivos conectados. Se ha convertido en el estándar de facto de la industria para conceder acceso a un conjunto de recursos, por ejemplo, API remotas o datos de usuario y para ello utiliza tokens de acceso.
Esto es lo que tienes que saber sobre él.
Índice de temas
OAUTH 2.0: orígenes
OAUTH 2.0 hace referencia a las siglas Open Authorization o autorización abierta. Se trata de un estándar diseñado para permitir que un sitio web o una aplicación accedan a recursos alojados por otras aplicaciones web en nombre de un usuario.
OAUTH 2.0 es ahora el estándar de facto de la industria para la autorización en línea
Este protocolo fue desarrollado en 2006 por la Internet Engineering Task Force (IETF) como un estándar abierto para la autorización y surgió para paliar la necesidad que se establece del envío continua de credenciales entre cliente y servidor.
Esta versión sustituyó a OAUTH 1.0 en 2012 y ahora es el estándar de facto de la industria para la autorización en línea. En concreto, este protocolo proporciona acceso consentido y restringe las acciones que la aplicación del cliente puede realizar en los recursos en nombre del usuario, sin compartir nunca las credenciales del usuario.
En otras palabras, OAUTH 2 es un framework de autorización que permite a las aplicaciones obtener acceso (limitado) a las cuentas de usuario de determinados servicios, como Facebook, GitHub, Twitter, Steam, BitBucket, LinkedIn y muchos más. Consiste en delegar la autenticación de usuario al servicio que gestiona las cuentas, de modo que sea éste quien otorgue el acceso para las aplicaciones de terceros. Es decir, el usuario delega la capacidad de realizar ciertas acciones, no todas, a las cuales da su consentimiento para hacerlas en su nombre.
Roles de OAUTH 2.0
Los roles definen los componentes esenciales de un sistema de OAUTH 2.0 y son:
Dueño del recurso: El usuario o sistema que posee los recursos protegidos y puede conceder acceso a ellos. La API no es suya, pero los datos que maneja sí lo son. Da autorización a una determinada aplicación para acceder a su cuenta y poder hacer algunas cosas en su nombre. El conjunto de cosas que puede hacer la aplicación en su nombre se llama alcance como, por ejemplo, acceso de lectura.
Cliente: El cliente es el sistema que requiere acceso a los recursos protegidos. Es la aplicación que desea acceder a esa cuenta de usuario (una aplicación web, un dispositivo IoT, etc). Para acceder a los recursos, el cliente debe poseer el token de acceso correspondiente.
Servidor de autorización: Este servidor recibe las solicitudes de tokens de acceso del cliente y las emite una vez que el propietario del recurso se ha autenticado y ha dado su consentimiento. El servidor de autorización expone dos puntos de conexión: el punto de conexión de autorización, que maneja la autenticación interactiva y el consentimiento del usuario, y el punto de conexión de token, que está involucrado en una interacción de máquina a máquina.
Servidor de recursos protegidos: Un servidor que protege los recursos del usuario y recibe las solicitudes de acceso del cliente. Acepta y valida un token de acceso del cliente y le devuelve los recursos adecuados. Es la API propiamente.
¿Cómo funciona el OAUTH?
Teniendo en cuenta estos roles podemos aclarar cómo funciona este estándar. Así, en el nivel más básico, antes de poder utilizar OAUTH 2.0, el cliente debe adquirir sus propias credenciales, un id de cliente y un client secret, del servidor de autorización para identificarse y autenticarse al solicitar un token de acceso.
Con este protocolo, las solicitudes de acceso son iniciadas por el cliente, por ejemplo, una aplicación móvil, un sitio web, una aplicación de televisión inteligente, una aplicación de escritorio, etc.
La solicitud, el intercambio y la respuesta de los tokens siguen el siguiente flujo general:
1.El cliente solicita autorización (solicitud de autorización) al servidor de autorización, proporcionando el id y el client secret como identificación; también proporciona los ámbitos y un URI de extremo (URI de redireccionamiento) al que enviar el token de acceso o el código de autorización.
2.El servidor de autorización autentica al cliente y verifica que los ámbitos solicitados están permitidos.
3.El propietario del recurso interactúa con el servidor de autorización para conceder el acceso.
4.El servidor de autorización redirige de vuelta al cliente con un código de autorización o un token de acceso, según el tipo de concesión, como se explicará en la siguiente sección. También puede devolverse un token de actualización.
5.Con el token de acceso, el cliente solicita acceso al recurso desde el servidor de recursos.
Funcionamiento para móviles u otros dispositivos
Aunque la web es la principal plataforma para OAUTH 2.0, esta especificación también describe cómo gestionar este modo de acceso delegado a otros tipos de clientes (aplicaciones basadas en el navegador, aplicaciones web del lado del servidor, aplicaciones nativas/móviles, dispositivos conectados, etc.).
Tokens: definición y gestión
Hay que aclarar que OAUTH 2.0 es un protocolo de autorización y no un protocolo de autenticación. Es por ello que está diseñado principalmente como un medio para conceder acceso a un conjunto de recursos, por ejemplo, API remotas o datos de usuario.
OAUTH 2.0 es un protocolo de autorización y no un protocolo de autenticación
Este estándar utiliza tokens de acceso. ¿Y qué es un token de acceso? Pues es un dato que representa la autorización para acceder a los recursos en nombre del usuario final. OAUTH 2.0 no define un formato específico para los tokens de acceso. Sin embargo, en algunos contextos, se suele utilizar el formato JSON Web Token (JWT). Esto permite a los emisores de tokens incluir datos en el propio token. Además, por razones de seguridad, los tokens de acceso pueden tener una fecha de caducidad.
¿Qué es OAUTH 2 JWT?
La diferencia entre OAUTH 2.0 y JWT es que, OAUTH es un framework que autoriza accesos a recursos de diversas aplicaciones por medio de un token, mientras que JWT es un protocolo de autenticación que genera, envía y valida el token de acceso.
Cumplen, pues, objetivos diferentes en el proceso de seguridad y protección de datos.
Tipos de concesiones
Cuando hablamos de OAUTH 2.0 es fundamental especificar qué son las concesiones. Estas son, ni más ni menos, que el conjunto de pasos que un cliente tiene que realizar para obtener la autorización de acceso a los recursos.
El marco de autorización proporciona varios tipos de concesión para hacer frente a diferentes escenarios:
Concesión del código de autorización: El servidor de autorización devuelve al cliente un código de autorización de un solo uso, que se intercambia por un token de acceso. Esta es la mejor opción para las aplicaciones web tradicionales en las que el intercambio puede realizarse de forma segura en el lado del servidor. El flujo del código de autorización puede ser utilizado por aplicaciones de página única (Single Page Apps, SPA) y aplicaciones móviles/nativas. Sin embargo, en este caso, el client secret no se puede almacenar de forma segura, por lo que la autenticación durante el intercambio se limita al uso del id del cliente únicamente.
Concesión implícita: Un flujo simplificado en el que el token de acceso se devuelve directamente al cliente. El servidor de autorización puede devolver el token de acceso como un parámetro en el URI de devolución de llamada o como una respuesta a la publicación de un formulario. La primera opción está ahora obsoleta debido a la posible fuga de tokens.
Concesión del código de autorización con clave de prueba para el intercambio de códigos (PKCE): Este flujo de autorización es similar a la concesión del código de autorización, pero con pasos adicionales que lo hacen más seguro para las aplicaciones móviles/nativas y SPA.
Tipo de concesión de credenciales del propietario del recurso: Requiere que el cliente adquiera primero las credenciales del propietario del recurso, que se pasan al servidor de autorización. Por lo tanto, se limita a los clientes de total confianza. Tiene la ventaja de que no implica ninguna redirección al servidor de autorización, por lo que es aplicable en los casos de uso en los que una redirección es inviable.
Tipo de concesión de credenciales de clientes: Se utiliza para aplicaciones no interactivas, por ejemplo, procesos automatizados, microservicios, etc. En este caso, la aplicación se autentica por sí misma mediante el uso de su id de cliente y su client secret.
Flujo de autorización de dispositivos: Una concesión que permite el uso de aplicaciones en dispositivos con restricciones de entrada, como las televisiones inteligentes.
Concesión del token de actualización: El flujo que implica el intercambio de un token de actualización por un nuevo token de acceso.
Tipos de clientes
Respecto a los tipos de clientes podríamos determinar que existen dos:
- Clientes confidenciales: son aquellos que son capaces de guardar una contraseña sin que sea expuesta. Una aplicación nativa compilada es un buen ejemplo de este tipo de clientes.
- Clientes públicos: son aquellos que no son capaces de mantener esta contraseña a salvo, como por ejemplo aplicaciones JavaScript, Angular, etcétera.
En función del tipo de cliente, se implementa un flujo de OAUTH 2.0 de diferentes formas.
¿Por qué utilizar OAUTH 2.0?
OAUTH 2.0 permite a los usuarios compartir datos de forma segura manteniendo la privacidad de sus nombres de usuario, contraseñas y otra información. A la vez que proporciona flujos de autorización seguros para aplicaciones web y de escritorio, así como para dispositivos móviles.
OAUTH 2.0 se usa mucho más de lo que creemos. Pongamos un ejemplo. Un usuario tiene una cuenta en Facebook o Twitter, y quiere acceder a otra plataforma, pero sin tener que registrarse. En este caso esa aplicación puede pedir al usuario que se autentique en Facebook o Twitter, y si considera que la información a la que le da acceso es correcta, le podría permitir realizar un conjunto cerrado de acciones dentro de su plataforma.
Gracias a este protocolo, esa plataforma de terceros no tendría por qué tener ese nombre de usuario ni la contraseña almacenados, sobre todo siendo un nombre de usuario y contraseña de otro servicio distinto, como podría ser alguna de estas redes sociales.
Vulnerabilidades
Con OAUTH 2.0 las aplicaciones pueden autenticar a los usuarios, pero entraña un problema y es que más del 41% de las aplicaciones que utilizan este estándar no validan los datos del usuario. Esto hace posible secuestrar las cuentas de redes sociales, por ejemplo.
Las posibles consecuencias de este exploit (programa informático que se aprovecha de un error para provocar un comportamiento no intencionado o imprevisto en un software, hardware o en cualquier dispositivo electrónico) son enormes. Muchas de las aplicaciones involucradas almacenan datos sensibles a la privacidad en la nube. Si un atacante inicia sesión como si fueras tú con una aplicación comprometida, todos sus datos estarán ahí.
