OAuth

Qué es OAuth en palabras sencillas

OAuth (Open Authorization) es un protocolo de autorización que permite a una aplicación obtener acceso a sus datos en otro servicio sin transferirle su inicio de sesión ni su contraseña. En lugar de la contraseña, la aplicación recibe una clave de acceso temporal especial (token).

En palabras sencillas, OAuth es como un pase digital que usted le da a un invitado para que pueda entrar en su piso, pero solo al vestíbulo, no a todas las habitaciones. Usted no le entrega las llaves de todas las puertas (su contraseña), sino solo un pase especial de un solo uso con derechos limitados.

Un ejemplo clásico es el botón «Iniciar sesión con Google» o «Iniciar sesión con VKontakte» en cualquier sitio web. Usted pulsa el botón, es redirigido a la página de Google, donde introduce su contraseña (¡pero no en un sitio de terceros!), confirma el acceso y el sitio recibe solo lo que usted permitió: por ejemplo, su nombre y su correo. Su contraseña permanece en secreto.

OAuth resuelve el problema principal de los sistemas antiguos: antes, las aplicaciones pedían su inicio de sesión y contraseña de otro servicio, lo que era extremadamente inseguro. Si la aplicación resultaba fraudulenta, usted perdía el acceso a toda la cuenta. OAuth otorga solo un acceso limitado a datos concretos durante un tiempo determinado. Según Okta, más del 80% de todas las aplicaciones corporativas utilizan OAuth para la autorización, y el número de tokens OAuth emitidos diariamente se mide en miles de millones.

Lea sobre cómo se relaciona OAuth con la seguridad de las aplicaciones web en el artículo Seguridad de la información.

Cómo funciona OAuth

El proceso de OAuth puede imaginarse como la obtención de un pase digital. En él participan cuatro partes:

• Propietario del recurso: usted, el usuario que posee los datos y otorga el permiso.
• Cliente: una aplicación de terceros que quiere acceder a sus datos (por ejemplo, una aplicación móvil o un sitio web).
• Servidor de autorización: el servidor que verifica su identidad y emite los tokens (por ejemplo, Google Accounts, GitHub).
• Servidor de recursos: el servidor donde se almacenan sus datos (por ejemplo, Google Drive o la API del perfil de VKontakte).

El proceso es el siguiente:

1. Usted pulsa «Iniciar sesión con Google» en un sitio web de terceros.
2. El sitio le redirige al servidor de Google, donde introduce su contraseña.
3. Google pregunta: «¿Permite usted que este sitio acceda a su nombre y correo?».
4. Usted pulsa «Permitir».
5. Google emite un código temporal al sitio y le redirige de nuevo.
6. El sitio cambia el código por un token de acceso.
7. El sitio usa el token para solicitar sus datos a la API de Google.

Lea sobre cómo funcionan los tokens en el artículo Token.

Tipos de concesión (grant) de OAuth 2.0

OAuth 2.0 admite varios flujos de autorización (grants) que se eligen según el tipo de aplicación (web, móvil, servidor) y el nivel de confianza:

• Authorization Code Grant: el flujo más común y seguro para aplicaciones web y móviles. El cliente recibe un código de autorización que luego cambia por un token de acceso. El código se transmite a través del navegador del usuario y el token, a través de un canal seguro entre el servidor del cliente y el servidor de autorización.
• Implicit Grant (desaprobado): un flujo simplificado para aplicaciones de una sola página (SPA) en el que el token se devuelve directamente al navegador. Se considera menos seguro y no se recomienda en la práctica moderna.
• Resource Owner Password Credentials Grant: un flujo en el que el usuario transfiere directamente su inicio de sesión y contraseña al cliente. Solo se utiliza para aplicaciones de confianza (por ejemplo, las aplicaciones móviles oficiales de los bancos). Un método de alto riesgo.
• Client Credentials Grant: se usa para la interacción servidor a servidor cuando no hay usuario. El cliente se autentica con sus credenciales (client ID y client secret) y recibe un token para acceder a los recursos protegidos.

Elegir el grant correcto es un paso de importancia crítica en el diseño de la seguridad de una aplicación. La elección incorrecta puede provocar vulnerabilidades y el compromiso de los datos.

OAuth 1.0 vs OAuth 2.0

OAuth 2.0 es una versión moderna del protocolo que sustituyó a OAuth 1.0. Las principales diferencias:

• Sencillez: OAuth 2.0 es significativamente más sencillo para los desarrolladores. No se requiere una compleja criptografía para firmar las solicitudes (en OAuth 1.0 había que generar una firma digital para cada solicitud).
• Flexibilidad: OAuth 2.0 admite distintos casos de uso: aplicaciones web, aplicaciones móviles, dispositivos sin navegador (IoT) e interacción servidor a servidor.
• Tokens: OAuth 2.0 usa tokens de acceso y tokens de actualización (refresh), lo que permite ampliar el acceso sin volver a introducir las credenciales del usuario.
• Seguridad: OAuth 2.0 admite la transmisión a través de HTTPS para proteger los tokens y se apoya más en TLS para la seguridad.

Hoy en día, OAuth 2.0 es el estándar de facto para la autorización en internet. Lo usan Google, Facebook, GitHub, Microsoft, Yandex y miles de otros servicios. Lea sobre cómo se integra OAuth con las APIs en el artículo Infraestructura.

Seguridad de OAuth

A pesar de que OAuth es un protocolo seguro, existen riesgos que es importante tener en cuenta al usarlo:

• Intercepción del token: si el atacante intercepta un token de acceso (por ejemplo, a través de una conexión insegura o de un ataque Man-in-the-Middle), puede utilizarlo antes de que caduque. El uso de HTTPS es obligatorio.
• Phishing: los atacantes pueden crear páginas de inicio de sesión falsas que imitan al servidor de autorización para robar las credenciales. Es importante comprobar siempre la URL antes de introducir la contraseña.
• Ataques CSRF (falsificación de peticiones en sitios cruzados): ataques en los que el atacante obliga al usuario a realizar acciones no deseadas en un sitio en el que está autenticado. Para protegerse, se usa el parámetro `state` en las solicitudes OAuth.
• Compromiso del client secret: si el atacante obtiene el client secret (la clave secreta de la aplicación), puede hacerse pasar por una aplicación legítima. Conserve el client secret en un lugar seguro.

Para mejorar la seguridad se recomienda una vida útil corta de los tokens de acceso (por ejemplo, 1 hora) y el uso de refresh tokens para ampliar la sesión sin teclear la contraseña. También es importante usar PKCE (Proof Key for Code Exchange) para protegerse contra la intercepción del código de autorización en las aplicaciones móviles.