OAuth 2.0: qué es y cómo funciona el protocolo de autorización

¿Qué es OAuth 2.0?

OAuth 2.0 es un protocolo de autorización definido en IETF RFC 6749 que permite a aplicaciones de terceros obtener acceso limitado a los recursos de un usuario sin revelar su nombre de usuario y contraseña. El protocolo resuelve un problema fundamental del modelo de contraseñas: una aplicación a la que confías tu contraseña obtiene acceso sin restricciones a todos los datos de la cuenta. OAuth 2.0 reemplaza este enfoque emitiendo un token temporal con un ámbito de acceso explícitamente limitado.

La arquitectura de OAuth 2.0 es la autorización delegada. El usuario (Resource Owner) autoriza a una aplicación (Client) a acceder a sus datos almacenados en un servidor de recursos (Resource Server) a través de un intermediario: el servidor de autorización (Authorization Server). El servidor de autorización emite un Access Token, una cadena criptográfica que la aplicación presenta al servidor de recursos para acceder a los datos. Una diferencia importante entre OAuth 2.0 y SAML u OpenID Connect: OAuth 2.0 resuelve la tarea de autorización (qué está permitido), no la autenticación (quién es el usuario). Para la autenticación sobre OAuth 2.0 se construye el protocolo OpenID Connect (OIDC).

El protocolo es compatible con todas las plataformas principales. Google utiliza OAuth 2.0 para acceder a las APIs de Google (Gmail, Drive, Calendar), Facebook para Graph API, Apple para Sign in with Apple (ASAuthorizationAppleIDProvider) y GitHub para el acceso a repositorios. En el contexto del desarrollo móvil, OAuth 2.0 es el mecanismo estándar para integrar servicios de terceros: inicio de sesión a través de redes sociales, acceso a almacenamiento en la nube y publicación de contenido en nombre del usuario.

Roles y componentes de OAuth 2.0

El protocolo OAuth 2.0 define cuatro roles cuya interacción forma el ciclo completo de autorización. Comprender cada rol es esencial para implementar correctamente el protocolo en una aplicación móvil.

Los cuatro roles del protocolo

Las entidades clave del protocolo son el Access Token, el Refresh Token y el Authorization Code. El Access Token es un token de corta duración (generalmente 15–60 minutos) que se presenta al servidor de recursos con cada solicitud de datos. El Refresh Token es un token de larga duración (días o semanas) utilizado para obtener un nuevo Access Token sin que el usuario tenga que volver a iniciar sesión. El Authorization Code es un código temporal emitido tras la autorización del usuario y canjeado por un Access Token y Refresh Token.

Grant Types: escenarios de autorización

OAuth 2.0 define varios Grant Types, escenarios de obtención de tokens, cada uno diseñado para un tipo específico de cliente y contexto de seguridad. Elegir el Grant Type correcto es una decisión arquitectónica crítica al diseñar la autorización en una aplicación móvil.

Los principales Grant Types son: Authorization Code (el más seguro para aplicaciones móviles y web con un componente de servidor), Authorization Code con PKCE (Proof Key for Code Exchange, para aplicaciones móviles y SPA sin backend de servidor), Client Credentials (para autenticación servidor a servidor sin participación del usuario) y Resource Owner Password Credentials (obsoleto: transmite la contraseña directamente). PKCE es una extensión obligatoria para clientes públicos (aplicaciones móviles, SPA) según las recomendaciones de OAuth Security BCP (RFC 9700).

Principales Grant Types

• Authorization Code + PKCE es el Grant Type recomendado para aplicaciones móviles nativas. El cliente genera un code_verifier criptográfico, calcula un code_challenge (hash SHA-256) y el servidor verifica la coincidencia al canjear el código por un token. Esto evita la interceptación del authorization code entre la aplicación y el servidor
• Client Credentials se utiliza para autorización machine-to-machine donde el cliente es conocido y autenticado. La aplicación obtiene un token usando su client_id y client_secret. No requiere participación del usuario. Escenario típico: una aplicación de servidor accede a una API para procesamiento por lotes de datos
• Device Authorization Grant está destinado a dispositivos sin navegador (Smart TV, IoT). El usuario sigue un enlace en otro dispositivo e introduce un código. Se utiliza, por ejemplo, al autorizar Netflix en un televisor a través de un smartphone
• Resource Owner Password Credentials es un Grant Type obsoleto prohibido por OAuth Security BCP. La contraseña se transmite directamente al cliente, violando el principio de autenticación con conocimiento cero. Solo se utiliza para migración desde sistemas heredados

Authorization Code Flow con PKCE para aplicaciones móviles

Authorization Code Flow con PKCE es la configuración recomendada de OAuth 2.0 para aplicaciones móviles nativas. PKCE (Proof Key for Code Exchange) añade una capa adicional de protección que evita los ataques de interceptación del authorization code. El protocolo se describe en IETF RFC 7636.

Secuencia paso a paso de PKCE

La secuencia de pasos: (1) el cliente genera un code_verifier aleatorio (una cadena de 43–128 caracteres usando solo caracteres no reservados), (2) el cliente calcula code_challenge = SHA-256(code_verifier), (3) el cliente abre un navegador para la autorización del usuario en el Authorization Server, pasando el code_challenge, (4) tras la autorización exitosa, el servidor devuelve el authorization code a la aplicación mediante un esquema URI personalizado (deep link de la aplicación), (5) el cliente envía el authorization code + code_verifier al servidor, (6) el servidor verifica SHA-256(code_verifier) === code_challenge y emite un Access Token + Refresh Token.

La ventaja de PKCE es que incluso si un atacante intercepta el authorization code en el esquema URI, no puede canjearlo por un token sin el code_verifier, que solo conoce el cliente legítimo. En aplicaciones móviles, para abrir el navegador se deben usar Chrome Custom Tabs (Android) o ASWebAuthenticationSession (iOS); esto garantiza que el navegador del sistema no tenga acceso al code_verifier desde la memoria de la aplicación.

Implementación de OAuth 2.0 en Android mediante AppAuth

AppAuth es la implementación de referencia de OAuth 2.0 y OpenID Connect para aplicaciones nativas, recomendada por IETF. La biblioteca admite PKCE, Chrome Custom Tabs, esquemas URI personalizados para devolver el authorization code y la actualización automática de tokens. AppAuth para Android está disponible a través de la dependencia `net.openid:appauth:0.11.1`.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Iniciar Chrome Custom Tab para autorización
startActivityForResult(intent, REQUEST_CODE_AUTH)

Tras recibir el authorization code (onActivityResult), la aplicación lo canjea por un Access Token y Refresh Token mediante un TokenRequest. Los tokens se guardan en SharedPreferences con cifrado mediante EncryptedSharedPreferences (Android Security Crypto). El Refresh Token debe almacenarse en KeyStore, un almacén de claves basado en hardware inaccesible para otras aplicaciones. Cada vez que el Access Token expira, la aplicación utiliza el Refresh Token para obtener uno nuevo: el usuario no necesita volver a autenticarse.

// Intercambiar authorization code por tokens
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token y Refresh Token recibidos
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Guardar en EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

El código anterior demuestra el flujo completo de OAuth 2.0 con PKCE: creación de la configuración del servidor mediante OpenID Connect Discovery, generación de una solicitud de autorización con code_verifier, inicio de Chrome Custom Tab, recepción del authorization code a través de un esquema URI personalizado y canje del código por tokens mediante un Token Request. Es importante manejar la expiración del Access Token: al recibir una respuesta HTTP 401 del Resource Server, la aplicación debe usar el Refresh Token para obtener un nuevo Access Token y volver a ejecutar la solicitud.

Seguridad de OAuth 2.0: ataques típicos y protección

OAuth 2.0 es un protocolo complejo con múltiples vectores de ataque. IETF Security BCP (RFC 9700) describe más de 20 clases de vulnerabilidades de OAuth 2.0. Para aplicaciones móviles, las más críticas son: interceptación del authorization code mediante esquemas URI personalizados, ataques CSRF en endpoints de callback, robo del Refresh Token desde almacenamiento inseguro y suplantación del cliente mediante interceptación de intents.

La protección contra estos ataques incluye medidas obligatorias: (1) PKCE con code_challenge S256: evita la interceptación del authorization code incluso si se intercepta el esquema URI; (2) uso de un parámetro nonce o state para prevenir CSRF: el servidor verifica que el authorization code corresponde a la solicitud original; (3) almacenamiento del Refresh Token solo en KeyStore (Android) o Keychain (iOS), nunca en SharedPreferences ni UserDefaults; (4) uso de TLS con Certificate Pinning para proteger contra MITM en la capa de transporte; (5) validación de redirect_uri: el servidor de autorización debe validar estrictamente la coincidencia con el URI registrado.

Recomendaciones adicionales de IETF: las aplicaciones móviles deben usar AppAuth o bibliotecas similares que hayan pasado auditorías de seguridad; no confiar en WebView para OAuth (WebView no aísla los datos de la aplicación principal); implementar rotación automática del Refresh Token (cada Refresh Token puede usarse una sola vez); añadir Certificate Pinning mediante TrustManager para Android y URLSession para iOS. OpenID Connect Discovery (endpoint well-known) ayuda a determinar automáticamente los endpoints correctos del servidor de autorización y evitar redirecciones a páginas de phishing.