Tutorial SpringBoot: Fundamentos de autenticación OAuth

OAuth 2: Roles y actores

OAuth 2.0 es un protocolo de autorización que permite a las aplicaciones obtener acceso limitado a recursos de usuario sin necesidad de que el usuario comparta sus credenciales directamente. 

En lugar de proporcionar tu nombre de usuario y contraseña a cada aplicación, OAuth actúa como un intermediario que gestiona los permisos de forma segura.

Para entender cómo funciona OAuth 2.0, es fundamental conocer los cuatro roles principales que participan en el proceso de autorización. Cada uno tiene responsabilidades específicas y se comunica con los demás siguiendo un protocolo bien definido.

Resource Owner (Propietario del recurso)

El Resource Owner es la entidad que posee los datos o recursos protegidos. En la mayoría de casos, se trata del usuario final que tiene una cuenta en un servicio y controla el acceso a su información personal.

Por ejemplo, cuando utilizas una aplicación de gestión de fotos que necesita acceder a tus imágenes almacenadas en Google Drive, tú eres el propietario del recurso. Tienes el derecho de decidir qué aplicaciones pueden acceder a tus archivos y qué nivel de acceso concederles.

El propietario del recurso tiene la capacidad de:

• Autorizar o denegar el acceso a sus recursos
• Definir qué permisos específicos concede a cada aplicación
• Revocar el acceso en cualquier momento

Resource Server (Servidor de recursos)

El Resource Server es el sistema que aloja y protege los recursos del usuario. Este servidor es responsable de validar los tokens de acceso y servir los recursos solicitados únicamente cuando la autorización es válida.

Siguiendo el ejemplo anterior, Google Drive actuaría como el servidor de recursos, ya que almacena tus archivos y debe verificar que cualquier solicitud de acceso esté debidamente autorizada antes de proporcionar los datos.

Las responsabilidades del servidor de recursos incluyen:

• Validar la autenticidad de los tokens de acceso
• Verificar que el token tenga los permisos necesarios para la operación solicitada
• Servir únicamente los recursos para los cuales existe autorización válida
• Registrar y monitorizar el acceso a los recursos

Client (Cliente)

El Client es la aplicación que solicita acceso a los recursos protegidos en nombre del propietario del recurso. Esta aplicación debe estar registrada previamente en el servidor de autorización para poder participar en el flujo OAuth.

En nuestro ejemplo, la aplicación de gestión de fotos sería el cliente. Esta aplicación necesita acceder a tus archivos de Google Drive para poder organizarlos o editarlos, pero no debe conocer tus credenciales de Google.

Los clientes pueden clasificarse en dos tipos principales:

• Clientes confidenciales: Aplicaciones que pueden mantener la confidencialidad de sus credenciales (aplicaciones web del lado del servidor)
• Clientes públicos: Aplicaciones que no pueden proteger sus credenciales de forma segura (aplicaciones móviles o de escritorio)

Authorization Server (Servidor de autorización)

El Authorization Server es el componente central que gestiona la autenticación del propietario del recurso y emite los tokens de acceso al cliente después de obtener la autorización correspondiente.

En el ecosistema de Google, el servidor de autorización de Google sería quien verifica tu identidad cuando inicias sesión y quien decide si conceder o no el acceso solicitado por la aplicación de fotos.

Este servidor tiene múltiples responsabilidades críticas:

• Autenticar al propietario del recurso
• Obtener la autorización del usuario para el acceso solicitado
• Emitir tokens de acceso y refresh tokens
• Validar las credenciales del cliente
• Gestionar el ciclo de vida de los tokens

Interacción entre los actores

La comunicación entre estos cuatro actores sigue un patrón específico que garantiza la seguridad del proceso. El cliente nunca accede directamente a los recursos sin autorización, y el propietario del recurso nunca comparte sus credenciales con aplicaciones de terceros.

El flujo básico implica que el cliente redirige al propietario del recurso al servidor de autorización, donde se autentica y concede permisos. Una vez autorizado, el servidor de autorización proporciona un token al cliente, que puede usar para acceder a los recursos en el servidor correspondiente.

Esta separación de responsabilidades es lo que hace que OAuth 2.0 sea tan efectivo para resolver los problemas de autorización en aplicaciones modernas. Cada actor tiene un papel específico y bien definido, lo que reduce la complejidad y mejora la seguridad del sistema en su conjunto.

La comprensión clara de estos roles es fundamental para entender cómo OAuth 2.0 facilita el acceso seguro a recursos sin comprometer las credenciales del usuario, estableciendo las bases para los diferentes flujos de autorización que veremos en las siguientes secciones.

Flujos de autorización (grant types)

Los flujos de autorización en OAuth 2.0 definen las diferentes formas en que un cliente puede obtener un token de acceso del servidor de autorización. Cada flujo está diseñado para adaptarse a distintos tipos de aplicaciones y escenarios de uso, considerando factores como la seguridad, la experiencia del usuario y las capacidades técnicas del cliente.

OAuth 2.0 especifica varios grant types o tipos de concesión, cada uno con sus propias características y casos de uso específicos. La elección del flujo adecuado depende principalmente del tipo de aplicación que estés desarrollando y del nivel de confianza que pueda establecerse entre los diferentes actores del sistema.

Authorization Code Grant

El Authorization Code Grant es el flujo más común y seguro para aplicaciones web que ejecutan código en el servidor. Este flujo utiliza un código de autorización temporal como paso intermedio antes de obtener el token de acceso final.

El proceso funciona de la siguiente manera: cuando el usuario necesita autorizar el acceso, el cliente lo redirige al servidor de autorización junto con parámetros que identifican la aplicación y los permisos solicitados. Una vez que el usuario se autentica y concede los permisos, el servidor de autorización redirige de vuelta al cliente con un código de autorización temporal.

Este código tiene una validez muy limitada (típicamente unos pocos minutos) y debe intercambiarse por el token de acceso real mediante una comunicación directa entre el cliente y el servidor de autorización. Esta comunicación se realiza en el canal de back-end, donde las credenciales del cliente pueden transmitirse de forma segura.

La principal ventaja de este flujo es que el token de acceso nunca pasa por el navegador del usuario, lo que reduce significativamente el riesgo de interceptación. Además, permite la emisión de refresh tokens para renovar el acceso sin requerir nueva autorización del usuario.

Implicit Grant

El Implicit Grant fue diseñado originalmente para aplicaciones que ejecutan completamente en el navegador, como las Single Page Applications (SPA) desarrolladas en JavaScript. En este flujo, el token de acceso se obtiene directamente sin el paso intermedio del código de autorización.

Cuando el usuario autoriza el acceso, el servidor de autorización redirige inmediatamente al cliente con el token de acceso incluido en la URL. Esto significa que el token es visible en el navegador y puede ser accedido por JavaScript ejecutándose en la página.

Aunque este flujo es más simple que el Authorization Code Grant, presenta consideraciones de seguridad importantes. El token de acceso queda expuesto en el historial del navegador y puede ser vulnerable a ataques de cross-site scripting (XSS). Por esta razón, los tokens emitidos mediante este flujo suelen tener una duración más corta y no se acompañan de refresh tokens.

Resource Owner Password Credentials Grant

El Resource Owner Password Credentials Grant permite que el cliente obtenga tokens de acceso utilizando directamente las credenciales del usuario (nombre de usuario y contraseña). Este flujo solo debe utilizarse cuando existe un alto nivel de confianza entre el usuario y la aplicación cliente.

En este escenario, el usuario proporciona sus credenciales directamente a la aplicación cliente, que las envía al servidor de autorización para obtener el token de acceso. Una vez obtenido el token, la aplicación debe descartar inmediatamente las credenciales del usuario.

Este flujo es apropiado principalmente para aplicaciones desarrolladas por la misma organización que opera el servidor de autorización, como aplicaciones móviles oficiales de un servicio. Su uso con aplicaciones de terceros está fuertemente desaconsejado debido a los riesgos de seguridad que implica compartir credenciales.

Client Credentials Grant

El Client Credentials Grant está diseñado para escenarios donde la aplicación cliente necesita acceder a recursos que le pertenecen directamente, sin actuar en nombre de un usuario específico. En este flujo, el cliente se autentica utilizando únicamente sus propias credenciales.

Este tipo de autorización es común en integraciones entre servicios, donde una aplicación necesita acceder a APIs para realizar tareas automatizadas o de mantenimiento. Por ejemplo, un servicio de backup que necesita acceder a datos de una aplicación para crear copias de seguridad programadas.

El proceso es directo: el cliente envía sus credenciales al servidor de autorización y recibe un token de acceso que le permite acceder a los recursos autorizados. No hay intervención del usuario en este flujo, ya que no existe un propietario de recurso humano en el proceso.

Consideraciones para la selección del flujo

La elección del flujo apropiado depende de varios factores técnicos y de seguridad. Para aplicaciones web tradicionales con backend seguro, el Authorization Code Grant ofrece el mejor balance entre seguridad y funcionalidad. Las aplicaciones móviles modernas también pueden beneficiarse de este flujo utilizando técnicas como PKCE (Proof Key for Code Exchange) para mejorar la seguridad.

Para aplicaciones que necesitan acceso automatizado sin intervención del usuario, el Client Credentials Grant es la opción natural. El Resource Owner Password Credentials Grant debe reservarse únicamente para casos donde la aplicación cliente es completamente confiable.

Es importante destacar que las mejores prácticas de seguridad han evolucionado, y algunos flujos como el Implicit Grant están siendo reemplazados por versiones mejoradas del Authorization Code Grant que ofrecen mejor protección contra amenazas modernas.

La comprensión de estos flujos te permitirá tomar decisiones informadas sobre qué tipo de autorización implementar según las características específicas de tu aplicación y los requisitos de seguridad de tu proyecto.

Tokens de acceso y refresh

Los tokens son el mecanismo fundamental que permite a las aplicaciones acceder a recursos protegidos sin necesidad de manejar directamente las credenciales del usuario. En OAuth 2.0, existen dos tipos principales de tokens que trabajan en conjunto para proporcionar un sistema de autorización seguro y eficiente.

Access Token (Token de acceso)

El access token es una credencial que representa la autorización concedida por el propietario del recurso al cliente. Este token actúa como una "llave digital" que permite a la aplicación acceder a recursos específicos durante un período limitado de tiempo.

Los tokens de acceso tienen varias características importantes que los hacen seguros y prácticos:

• Alcance limitado: Cada token está asociado a permisos específicos (scopes) que definen exactamente qué recursos puede acceder la aplicación
• Duración limitada: Tienen un tiempo de vida corto, típicamente entre 15 minutos y 2 horas
• Opacidad: Para el cliente, el token es una cadena opaca sin significado interno aparente
• Portabilidad: Pueden incluirse en las peticiones HTTP para autenticar el acceso a recursos

Cuando una aplicación necesita acceder a un recurso protegido, incluye el access token en la cabecera de autorización de la petición HTTP. El servidor de recursos valida este token antes de proporcionar acceso a los datos solicitados.

La vida útil limitada de los access tokens es una característica de seguridad fundamental. Si un token es comprometido, el daño potencial se limita al período de validez restante. Una vez que expira, el token se vuelve inútil para cualquier atacante que pudiera haberlo interceptado.

Refresh Token (Token de renovación)

El refresh token es una credencial de larga duración que permite al cliente obtener nuevos access tokens sin requerir nueva autorización del usuario. Mientras que los access tokens son de corta duración, los refresh tokens pueden ser válidos durante días, semanas o incluso meses.

Este mecanismo resuelve un problema fundamental en la experiencia del usuario: sin refresh tokens, las aplicaciones tendrían que solicitar autorización cada vez que expira un access token, lo que resultaría en interrupciones constantes y una experiencia frustrante.

Los refresh tokens tienen características distintivas:

• Larga duración: Su tiempo de vida es significativamente mayor que los access tokens
• Uso único o limitado: Algunos servidores invalidan el refresh token después de cada uso, emitiendo uno nuevo junto con el access token
• Almacenamiento seguro: Deben guardarse de forma más segura que los access tokens debido a su mayor duración
• Revocación: Pueden ser revocados por el usuario o el servidor de autorización en cualquier momento

Ciclo de vida de los tokens

El funcionamiento conjunto de ambos tipos de tokens crea un sistema equilibrado entre seguridad y usabilidad. Inicialmente, cuando se completa el flujo de autorización, el servidor emite tanto un access token como un refresh token al cliente.

La aplicación utiliza el access token para realizar peticiones a los recursos protegidos. Cuando este token está próximo a expirar o ya ha expirado, la aplicación puede utilizar el refresh token para solicitar un nuevo par de tokens al servidor de autorización.

Este proceso de renovación ocurre de forma transparente para el usuario. La aplicación gestiona automáticamente la renovación de tokens en segundo plano, manteniendo el acceso a los recursos sin interrumpir la experiencia del usuario.

Formatos y estructura de tokens

Los tokens pueden implementarse de diferentes formas según las necesidades del sistema. Los tokens opacos son cadenas aleatorias que no contienen información legible, requiriendo que el servidor de recursos consulte al servidor de autorización para validar cada token.

Por otro lado, los JSON Web Tokens (JWT) son tokens auto-contenidos que incluyen información sobre los permisos y la expiración directamente en su estructura. Esto permite que los servidores de recursos validen tokens localmente sin necesidad de consultas adicionales.

Los JWT están compuestos por tres partes separadas por puntos: header, payload y signature. El payload contiene información como el identificador del usuario, los scopes autorizados, el tiempo de expiración y otros metadatos relevantes para la autorización.

Gestión y seguridad de tokens

La gestión adecuada de tokens es crucial para mantener la seguridad del sistema. Los access tokens deben transmitirse únicamente a través de conexiones seguras (HTTPS) y nunca deben almacenarse en ubicaciones vulnerables como el almacenamiento local del navegador para aplicaciones web.

Los refresh tokens requieren un nivel de protección aún mayor debido a su larga duración. Deben almacenarse en ubicaciones seguras y, preferiblemente, estar asociados a la aplicación específica que los utiliza para prevenir su uso no autorizado.

La rotación de refresh tokens es una práctica de seguridad recomendada donde cada vez que se utiliza un refresh token para obtener un nuevo access token, también se emite un nuevo refresh token, invalidando el anterior. Esto limita la ventana de oportunidad para ataques basados en tokens comprometidos.

El sistema de tokens en OAuth 2.0 proporciona un equilibrio óptimo entre seguridad, rendimiento y experiencia del usuario, permitiendo que las aplicaciones mantengan acceso autorizado a recursos sin comprometer las credenciales del usuario ni requerir autorizaciones repetitivas innecesarias.

Scopes

Los scopes (ámbitos o alcances) son un mecanismo fundamental en OAuth 2.0 que define y limita los permisos específicos que una aplicación puede ejercer sobre los recursos de un usuario. Funcionan como un sistema de permisos granulares que permite al propietario del recurso controlar exactamente qué acciones puede realizar una aplicación en su nombre.

Cuando una aplicación solicita autorización, debe especificar qué scopes necesita para funcionar correctamente. El usuario puede entonces revisar y aprobar estos permisos específicos, en lugar de conceder acceso total a todos sus recursos. Esta granularidad es esencial para mantener el principio de menor privilegio en sistemas de autorización modernos.

Definición y estructura de scopes

Un scope se representa típicamente como una cadena de texto que describe un permiso específico. Estas cadenas suelen seguir convenciones que hacen que su propósito sea evidente tanto para desarrolladores como para usuarios finales.

Por ejemplo, en una API de gestión de archivos, podrías encontrar scopes como:

• files:read - Permite leer archivos del usuario
• files:write - Permite crear y modificar archivos
• files:delete - Permite eliminar archivos
• profile:basic - Acceso a información básica del perfil
• profile:email - Acceso a la dirección de correo electrónico

La nomenclatura jerárquica ayuda a organizar los permisos de forma lógica. Algunos proveedores utilizan puntos como separadores (user.profile.read), mientras que otros prefieren dos puntos (user:profile:read) o guiones (user-profile-read).

Solicitud de scopes durante la autorización

Durante el flujo de autorización, el cliente debe incluir los scopes requeridos como parte de la petición inicial al servidor de autorización. Esta información se envía típicamente como un parámetro llamado scope que contiene una lista de permisos separados por espacios.

El servidor de autorización presenta entonces al usuario una pantalla de consentimiento que muestra claramente qué permisos está solicitando la aplicación. Esta transparencia permite al usuario tomar una decisión informada sobre si conceder o denegar el acceso.

Es importante destacar que el usuario puede aprobar parcialmente los scopes solicitados. Si una aplicación solicita cinco permisos diferentes, el usuario podría decidir conceder solo tres de ellos. La aplicación debe estar preparada para manejar esta situación y adaptar su funcionalidad según los permisos realmente concedidos.

Scopes en tokens de acceso

Una vez completado el proceso de autorización, los scopes aprobados quedan asociados al token de acceso emitido. Esto significa que cada token lleva consigo información sobre exactamente qué permisos puede ejercer la aplicación que lo posee.

Cuando el servidor de recursos recibe una petición con un token de acceso, no solo valida la autenticidad del token, sino que también verifica que los scopes asociados incluyan los permisos necesarios para la operación solicitada. Si el token no tiene el scope apropiado, la petición se rechaza con un error de autorización insuficiente.

Esta validación ocurre en tiempo real para cada petición, lo que significa que los permisos se aplican de forma consistente y inmediata. No existe riesgo de que una aplicación acceda a recursos para los cuales no tiene autorización, incluso si las circunstancias cambian después de la emisión del token.

Tipos de scopes comunes

Los scopes estándar varían según el tipo de servicio, pero existen patrones comunes que se repiten en muchas implementaciones:

Scopes de lectura (read, view, get) permiten a las aplicaciones consultar información sin modificarla. Estos suelen ser los permisos más básicos y menos sensibles.

Scopes de escritura (write, create, update) otorgan capacidad de modificar o crear nuevos recursos. Requieren mayor nivel de confianza por parte del usuario.

Scopes de eliminación (delete, remove) son típicamente los más restrictivos, ya que las acciones de eliminación suelen ser irreversibles.

Scopes administrativos (admin, manage) proporcionan permisos elevados para gestionar configuraciones o realizar acciones que afectan a otros usuarios.

Scopes dinámicos y contextuales

Algunos sistemas implementan scopes dinámicos que pueden modificarse según el contexto de la petición. Por ejemplo, un scope como files:read:folder123 podría limitar el acceso de lectura únicamente a una carpeta específica.

Esta aproximación permite un control de acceso muy granular, donde los permisos pueden definirse no solo por tipo de operación, sino también por recursos específicos o condiciones contextuales como la ubicación geográfica o el horario de acceso.

Los scopes contextuales son especialmente útiles en aplicaciones empresariales donde diferentes usuarios pueden necesitar acceso a subconjuntos específicos de datos según su rol organizacional o proyecto asignado.

Mejores prácticas para el diseño de scopes

Al diseñar un sistema de scopes, es fundamental seguir el principio de menor privilegio. Las aplicaciones deben solicitar únicamente los permisos mínimos necesarios para su funcionamiento, evitando solicitar accesos "por si acaso" que podrían no utilizarse nunca.

La nomenclatura clara y consistente facilita tanto el desarrollo como la comprensión del usuario. Los nombres de scopes deben ser descriptivos y seguir convenciones establecidas que hagan evidente su propósito.

Es recomendable agrupar scopes relacionados de forma lógica y proporcionar descripciones amigables para el usuario en las pantallas de consentimiento. En lugar de mostrar user:profile:email:read, es mejor mostrar "Acceder a tu dirección de correo electrónico".

La documentación exhaustiva de todos los scopes disponibles es esencial para que los desarrolladores puedan integrar correctamente con tu API y solicitar únicamente los permisos apropiados para sus casos de uso específicos.

Los scopes representan la interfaz de control de acceso más visible para los usuarios finales en OAuth 2.0, por lo que su diseño e implementación correcta es crucial para crear sistemas de autorización que sean tanto seguros como usables.