RFC 6749

Definicion

¿Alguna vez has querido que una app acceda a tus fotos de Facebook, o que un sitio web publique tweets en tu nombre, sin tener que darles tu contraseña real? Exactamente ese es el problema que resuelve RFC 6749. Es la especificación oficial que define OAuth 2.0, el framework de autorización más utilizado en internet hoy en día.

Antes de OAuth 2.0, la única forma de permitir que apps de terceros accedieran a tus cuentas era literalmente entregarles tu usuario y contraseña. Esto era una pesadilla de seguridad. Si esa app era hackeada, o si era maliciosa desde el principio, toda tu cuenta quedaba comprometida. Tendrías que cambiar tu contraseña en todos lados, y no había manera de limitar lo que la app podía hacer con tus credenciales.

RFC 6749 introduce un enfoque mucho más inteligente: en lugar de compartir contraseñas, autorizas a las apps para que reciban tokens especiales que otorgan acceso limitado y temporal a funciones específicas de tu cuenta. Piénsalo como la diferencia entre darle a alguien la llave de tu casa versus darle una tarjeta de acceso temporal que solo funciona para el garaje durante horario de oficina. La especificación define cuatro “tipos de concesión” (grant types) diferentes para cubrir distintos escenarios - desde apps web hasta apps móviles y comunicación servidor a servidor.

Ejemplo

Iniciar sesión con Google en Spotify: Cuando tocas “Continuar con Google” en Spotify, la app te redirige a la página de login de Google. Google te pregunta si quieres permitir que Spotify vea tu email y foto de perfil. Cuando apruebas, Google le da a Spotify un token especial - Spotify nunca ve tu contraseña de Google, pero puede leer tu información básica de perfil.

Conectar Instagram a una herramienta de programación: Los community managers usan herramientas como Buffer o Hootsuite para programar publicaciones. Estas herramientas usan OAuth 2.0 para obtener permiso de publicar en tu nombre. Inicias sesión directamente en Instagram, apruebas los permisos, y la herramienta de programación recibe un token que le permite publicar por ti - nada más.

Dispositivos de hogar inteligente: Cuando vinculas tu termostato Nest con Google Assistant, OAuth 2.0 maneja la autorización. Google Assistant obtiene un token que le permite controlar tu termostato, pero no puede acceder a las grabaciones de tu cámara Nest a menos que le concedas ese permiso adicional explícitamente.

Apps bancarias usando servicios fintech: Cuando conectas tu cuenta bancaria a apps como Fintonic o Wallet para presupuestos, muchos bancos ahora usan OAuth 2.0. La app de presupuestos obtiene acceso de solo lectura a tus transacciones sin jamás conocer tu contraseña bancaria.

Analogia

La Llave del Valet: Muchos coches de lujo vienen con una “llave de valet” especial que solo arranca el motor y bloquea el maletero - no puede abrir la guantera ni acceder a todas las funciones del coche. OAuth 2.0 es como darle a una app una llave de valet en lugar de tu llave maestra. Estás concediendo acceso limitado para un propósito específico, y puedes revocar esa llave en cualquier momento sin cambiar tus credenciales principales.

La Tarjeta del Hotel: Cuando te registras en un hotel, no te dan una llave maestra - te dan una tarjeta que abre tu habitación, quizás la zona de piscina y el gimnasio, pero nada más. Y expira cuando haces el checkout. Los tokens de OAuth funcionan igual: conceden acceso a recursos específicos y tienen fecha de expiración. Si pierdes la tarjeta, simplemente la desactivas en recepción (revocas el token).

La Autorización para la Niñera: Imagina que dejas a tus hijos con una niñera. Podrías darle autorización para pedir pizza, recoger a los niños del colegio y acceder al botiquín - pero no para organizar una fiesta o conducir tu coche. Estás delegando permisos específicos. OAuth 2.0 permite a los usuarios delegar permisos específicos a las apps exactamente de esta manera.

La Tarjeta de Seguridad del Edificio: En un edificio de oficinas, diferentes tarjetas dan acceso a diferentes zonas. Una tarjeta de empleado podría abrir la puerta principal y tu planta, pero no la sala de servidores o la suite ejecutiva. Los scopes de OAuth funcionan como estos permisos de tarjeta - cada token viene con un conjunto específico de derechos de acceso.

Code Example

// Authorization Code Flow (el más seguro)
// 1. El cliente redirige al usuario al servidor de autorización
GET https://auth.example.com/authorize?
  response_type=code&
  client_id=CLIENT_ID&
  redirect_uri=https://app.com/callback&
  scope=read:profile&
  state=xyz123

// 2. El usuario aprueba, el servidor redirige de vuelta con código
https://app.com/callback?code=AUTH_CODE&state=xyz123

// 3. El cliente intercambia el código por un access token
POST https://auth.example.com/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=https://app.com/callback&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET

// 4. Respuesta con access token
{
  "access_token": "eyJhbGc...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0..."
}

Notas de Seguridad