Entendiendo el protocolo OAuth2: autorización, tokens y seguridad

OAuth2 es un protocolo estándar de autorización que permite a las aplicaciones acceder a recursos protegidos de un usuario sin necesidad de conocer su contraseña. En otras palabras, OAuth2 permite delegar el acceso de manera segura: una aplicación puede operar en nombre del usuario, accediendo a sus datos, siempre que este lo autorice explícitamente.

 

 

La clave del protocolo es que nunca compartimos nuestras credenciales reales (como contraseñas) con la aplicación cliente. En su lugar, se emite un access token, que actúa como un permiso temporal para acceder a determinadas APIs o recursos del usuario.

 

OAuth2 se ha convertido en el mecanismo de autorización estándar en aplicaciones modernas, especialmente en entornos web y móviles. Plataformas como Google, GitHub, Facebook o Microsoft lo implementan para permitir el inicio de sesión con cuenta externa y acceso delegado a sus servicios.

 

Ventajas y desventajas de usar OAuth2

 

Como siempre solemos hacer, una vez sabemos lo que es OAuth2, vamos a echar un vistazo a las ventajas y desventajas de utilizar este protocolo en nuestra app.

 

✅ Ventajas:

• Sin necesidad de nueva cuenta: el usuario usa las credenciales del proveedor de Autorización (Google, GitHub, Keycloak, etc.).

• Sin gestión de contraseñas: no se gestionan las contraseñas en tu app, con lo que el riesgo de brechas es menor.

• Seguridad delegada: el proveedor de autenticación puede aplicar autenticación multifactor, detección de anomalías, etc.

• Mejor experiencia de usuario: el login se reduce a pocos clics.

• Acceso a datos del perfil: con consentimiento, la app puede obtener nombre, email, foto, etc.

❌ Desventajas:

• Dependencia externa: si el Auth Server falla o cambia la API, la app puede verse afectada.

• Registro obligatorio de la app: hay que registrar la aplicación en el servidor de autorización y obtener client_id y client_secret.

• El usuario necesita una cuenta en el Auth Server: lo que puede limitar el uso en entornos corporativos cerrados.

   

   

 

🔑 Diferencia entre Autenticación y Autorización

 

Es común confundir los conceptos de Autorización y de Autenticación, especialmente porque comparten infraestructura en OAuth2:

• Autorización (¿A qué puedes acceder?)
  La app cliente necesita permiso para acceder a un recurso. Aquí el Auth Server del proveedor emite un Access Token, que no contiene información personal, pero permite acceder a las APIs de los recursos precisados. Ejemplos: acceder a tu Drive, a tu Calendar o a tu Dropbox.

• Autenticación (¿Quién eres?)
  La app cliente necesita saber la identidad del usuario. El Auth Server devuelve un ID Token (normalmente en OpenID Connect), que incluye datos del usuario como su nombre o email. Este token se utiliza en la app para verificar la identidad. Ejemplos: Login en una app con Google, Mostrar “hola, Juan” tras el login.

   

 Recuerda: Si la app cliente también necesita saber la identidad del usuario, entonces necesita un ID token. Eso lo hace el protocolo OpenID Connect, que amplía OAuth. 

 

🔎 Muchos proveedores (como Google o GitHub) combinan ambos protocolos: autenticación vía OpenID Connect junto con autorización vía OAuth2. Por eso sus Auth Servers usan a la vez access_token e id_token.

 

🧩 Componentes implicados en OAuth2

 

Antes de entrar en el detalle de cómo sería el flujo de una petición con el protocolo OAuth2, vamos a hacer un repaso rápido de cuáles serían las entidades principales en este tipo de autorización. 

• Resource Owner: el usuario final que posee los datos.

• Client: la aplicación que quiere acceder a esos datos.

• Authorization Server: el servidor que autentica al usuario y emite los tokens.

• Resource Server: el servidor donde residen los recursos protegidos (normalmente una API).

• Access Token: credencial que permite a la app Client acceder a los recursos destino.

• Refresh Token: utilizado para obtener un nuevo Access Token sin que el usuario inicie sesión.

 

🔎 Ejemplo real: tú (owner) autorizas a una app móvil (client) a leer tu calendario en Google (resource server), y es Google quien autentica y genera el token (authorization server).

 

 

🔁 Flujo típico de OAuth2 paso a paso

 

Y ahora sí, una vez conocemos los componentes principales del protocolo, vamos a ir viendo cúal sería el flujo típico de una petición en OAuth2.

 

1. Inicio del usuario: el usuario entra en la app cliente y solicita acceder a un recurso (por ejemplo: Google Drive).

2. Redirección al Auth Server: la app redirige al usuario al servidor de autorización (ejemplo: Auth Server de Google).

3. Permiso del usuario: el usuario autoriza que la app acceda a su recurso.

4. Código de autorización: el Auth Server devuelve un Authorization Code temporal (no confundir con el token posterior, se trata de un código temporal previo).

5. Intercambio por token: la app usa ese código, junto con sus propias credenciales (client_id y client_secret), para solicitar un Access Token al Auth Server. Por tanto, obviamente, la app cliente debe estar registrada con credenciales en el Auth Server.

6. Acceso al recurso: con el token, la app accede a la API del Resource Server, esto es, al servidor donde están almacenados los recursos a los que se quería acceder inicialmente (en nuestro ejemplo, era el Google Drive).

7. Datos devueltos: el Resource Server valida el token de acceso y devuelve los datos solicitados.

  

Como se aprecia en el flujo, en todo momento, la contraseña del usuario sólo se introduce en el Auth Server (por lo que es un dato desconocido en la app cliente). 

 

 

🔐 Tipos de acceso en OAuth2 (Grants)

 

Dependiendo del tipo de aplicación, OAuth2 permite varias tipologías de flujos o grants (aunque hoy en día el tipo estándar sería el "Authorization Code"). Los tipos son los siguientes:

• Authorization Code: el más seguro, usado por apps web y móviles. Se trata del único tipo permitido si lo queremos utilizar en conjunción con el protocolo OpenID Connect.

• Refresh Token: sirve para renovar el access_token sin que el usuario tenga que hacer login de nuevo. Se trata de una extensión del primer tipo.

• Client Credentials: usado entre servidores o servicios backend (por ejemplo, comunicaciones entre microservicios).

• Password Credentials: menos recomendado, se usa cuando el usuario introduce su user/password en la app cliente. Obsoleto en Spring Security desde la versión 5.

• Implicit: usado por apps frontend sin backend, hoy en día en desuso por cuestiones de seguridad. Obsoleto en Spring Security desde la versión 5.

 

 

🔄 Flujo de acceso con Authorization Code

 

Tal y como hemos dicho antes, el Authorization Code es el flujo estándar en aplicaciones web. Por tanto, para tener un poco más claro su funcionamiento, vamos a ver con un ejemplo práctico de cómo se gestionaría una petición con este tipo de grant.

 

📌 Ejemplo:

1. Un usuario accede a una app web que quiere conectarse a su calendario de Google.
2. La app redirige al usuario a Google con una petición que incluye:
• Su client_id
• El scope (lo que quiere acceder, ej: calendar.read)
• Una URL de redirección
3. El Auth Server de Google solicita el login. 
4. El usuario inicia sesión en Google y acepta los permisos.
5. Google redirige al navegador con un Authorization Code.
6. La app (en el backend) hace una petición a Google con:
• El Authorization Code
• Su client_id y client_secret
7. El Auth Server valida las credenciales y el authorization code. 
8. Google responde con un access_token (y opcionalmente, un refresh_token y un id_token).
9. La app ya puede usar el access_token para acceder a la API de Google Calendar en nombre del usuario. 
10. El Resource Server destino de Google valida el Access Token enviado. 
11. Si todo es correcto, se devuelve a la app el calendario de Google.

 

 

 ⚠️ La seguridad del flujo está en que el Authorization Code sólo se puede intercambiar desde el backend (con secreto), lo cual evita fugas de tokens en el frontend.

 

No confundir password del usuario con el secret de la App cliente.

• El usuario hace login con “password” en el Authentication Server.
• La app cliente hace login en Auth Server con su ID, su “secret” y el Authorization Code temporal.

 

Conclusión

 

OAuth2 es un protocolo robusto y flexible que se ha convertido en el estándar de facto para acceder a APIs y proteger recursos en internet. Su filosofía de "acceso delegado" mejora la seguridad de las aplicaciones y la experiencia del usuario al evitar gestión directa de credenciales.

 

Si estás creando una app que requiere acceso a datos del usuario en servicios externos, OAuth2 es la opción correcta. Solo asegúrate de elegir el flujo adecuado, proteger correctamente tus secretos y aplicar buenas prácticas como el uso de HTTPS y expiración de tokens.

 

¡Nos vemos en el siguiente post!

Saludos.