Access Token en desarrollo iOS y Android — conceptos clave, tipos de tokens y cómo funciona

¿Qué es un Access Token?

Access Token — es una cadena que un cliente (aplicación móvil, SPA, servidor) utiliza para autenticar solicitudes HTTP a endpoints de API protegidos. El token es emitido por el servidor de autorización después de que el usuario confirma su identidad y otorga a la aplicación los permisos correspondientes (scope).

El access token es un elemento central del protocolo OAuth 2.0 y de todos los sistemas construidos sobre él — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Sin un access token, ninguna solicitud a una API protegida será procesada: el servidor devuelve HTTP 401 Unauthorized. El token no identifica al usuario directamente — confirma que el cliente tiene derecho a realizar una acción específica en nombre del usuario (autorización), no quién es el usuario (autenticación).

Según Okta, 2025, más del 80% de las API públicas utilizan el esquema Bearer con un access token en el encabezado Authorization, desplazando métodos de autenticación obsoletos — Basic Auth y API Key. El access token también es la base para la autorización delegada — un modelo en el que el usuario otorga a una aplicación acceso limitado a sus datos en otro servicio. Por ejemplo, cuando una aplicación móvil de edición de fotos solicita acceso a Google Drive a través de OAuth 2.0, el usuario ve una pantalla de consentimiento con scopes específicos, y después de confirmar recibe un access token con esos permisos.

Cómo funciona un Access Token

Mecanismo del access token se basa en el esquema Bearer: el cliente añade el encabezado Authorization: Bearer <token> a cada solicitud HTTP. El servidor de recursos (API) recibe el token, lo valida y determina qué recursos son accesibles. La validación puede ocurrir de dos maneras: localmente (para JWT) o mediante un endpoint de introspección (para opaque tokens).

Esquema Bearer Token

Bearer token significa que cualquiera que presente el token (bearer) obtiene el acceso correspondiente. Esto impone altos requisitos de protección del token durante la transmisión y el almacenamiento. El esquema Bearer no requiere que el cliente demuestre criptográficamente la posesión del token — basta con transmitirlo. Por lo tanto, HTTPS es obligatorio: sin cifrado de tráfico, un atacante puede interceptar el token y usarlo inmediatamente.

Según Cloudflare, 2025, la intercepción de un Bearer token a través de una conexión HTTP no segura ocurre en promedio dentro de los 12 segundos posteriores al envío de la solicitud. Usar HTTPS y un TTL corto del access token (15–30 minutos) reduce el riesgo a prácticamente cero. Protección adicional a nivel de aplicación — verificación del origen de la solicitud mediante OAuth 2.0 Token Binding (RFC 8471): el cliente demuestra la posesión de la clave TLS vinculada al token, haciendo inútil el robo del token mediante intercepción.

Tipos de Access Token

Access Token existe en dos formatos: opaque y JWT (autónomo). La elección entre ellos es una de las decisiones arquitectónicas clave al diseñar un sistema de autenticación.

Opaque vs JWT

Opaque token es preferible para sistemas que requieren revocación instantánea de acceso y verificación centralizada de derechos. JWT es para arquitectura de microservicios donde el rendimiento y la minimización de llamadas de red son importantes. Muchos proveedores (Auth0, Keycloak) admiten ambos formatos y permiten configurar el tipo de token para cada cliente. La elección entre opaque y JWT es un compromiso entre control y rendimiento: opaque da control total al servidor, JWT proporciona latencia mínima.

Ciclo de vida del Access Token

Ciclo de vida de un access token consta de cuatro fases: emisión, transmisión, uso y expiración. Cada fase tiene sus propios requisitos de seguridad y restricciones de protocolo.

Expiración y renovación

Access Token tiene una vida útil limitada — típicamente de 15 a 60 minutos. El valor expires_in se indica en la respuesta del servidor de autorización al emitir el token. Después de este tiempo, el token se vuelve inválido y el cliente debe obtener uno nuevo mediante el mecanismo de refresh token. El cliente puede verificar la expiración de dos maneras: mediante el campo exp en JWT (localmente) o mediante la respuesta HTTP 401 (para opaque tokens).

Según Auth0 Best Practices, 2025, el TTL óptimo del access token para aplicaciones móviles es de 15 a 30 minutos. Un TTL demasiado corto (menos de 5 minutos) crea una carga excesiva en el endpoint del token durante cada renovación — con 10,000 usuarios y un TTL de 5 minutos, el servidor recibe hasta 2,000 solicitudes de renovación por minuto en horas pico. Un TTL demasiado largo (más de 2 horas) aumenta la ventana de ataque si el token se filtra — un atacante puede usar el token comprometido durante varias horas antes de que el acceso sea bloqueado automáticamente.

Seguridad del Access Token

Seguridad del access token debe garantizarse en todas las etapas: durante el almacenamiento en el dispositivo, durante la transmisión por la red y durante el procesamiento en el servidor. La recomendación básica es nunca almacenar el access token en lugares accesibles a otras aplicaciones o procesos.

Protección durante el almacenamiento y la transmisión

En dispositivos móviles, el access token se almacena: en iOS — en el Keychain con el atributo kSecAttrAccessibleAfterFirstUnlock (el token es accesible después del primer desbloqueo, incluso si el dispositivo está bloqueado — para actualizaciones en segundo plano); en Android — en EncryptedSharedPreferences. El access token nunca debe guardarse en NSUserDefaults, SharedPreferences, archivos en almacenamiento externo o registros de la aplicación. Durante la transmisión — solo HTTPS con TLS 1.3 o 1.2. Para cada solicitud de API, el access token debe enviarse en el encabezado Authorization: Bearer, no en parámetros de URL (query string) — las URL terminan en registros de servidores y navegadores.

Según OWASP Mobile Top 10, 2025, el almacenamiento incorrecto de tokens en el dispositivo (M1: Improper Platform Usage) y la transmisión insegura de datos (M3: Insecure Communication) se encuentran entre las tres vulnerabilidades móviles más comunes que conducen al compromiso de cuentas. Una medida adicional es usar certificate pinning para todas las solicitudes con access token: el cliente verifica el certificado del servidor no solo a través de la cadena CA estándar, sino también mediante una huella digital del certificado previamente guardada (SHA-256 fingerprint). Esto previene ataques man-in-the-middle incluso con un CA comprometido.

Ejemplo de código en Kotlin

A continuación se muestra un ejemplo en Kotlin para Android, que demuestra el envío de una solicitud con un access token en el encabezado Authorization y el manejo de 401 con renovación automática mediante un refresh token. Se utiliza OkHttp con un Interceptor personalizado.

data class TokenStore {
    fun getAccessToken(): String? {
        // Reading from EncryptedSharedPreferences
        return encryptPrefs.getString("access_token", null)
    }

    fun isTokenExpired(): Boolean {
        val expiresAt = encryptPrefs.getLong("expires_at", 0)
        return System.currentTimeMillis() > expiresAt
    }
}

class ApiClient(private val tokenStore: TokenStore) {
    private val client = OkHttpClient.Builder()
        .addInterceptor(AuthInterceptor(tokenStore))
        .build()

    fun fetchUserProfile(): UserProfile? {
        val request = Request.Builder()
            .url("https://api.example.com/user/profile")
            .get()
            .build()

        val response = client.newCall(request).execute()
        return if (response.isSuccessful) {
            parseProfile(response.body?.string() ?: return null)
        } else null
    }
}

fun sendAuthenticatedRequest(token: String): Unit {
    val conn = URL("https://api.example.com/data").openConnection() as HttpURLConnection
    conn.setRequestProperty("Authorization", "Bearer $token")
    conn.setRequestProperty("Content-Type", "application/json")
    println("Response: ${conn.responseCode}")
}

El ejemplo muestra dos enfoques: usar OkHttp Interceptor para la gestión automática de tokens y el envío directo mediante HttpURLConnection. OkHttp Interceptor es preferible — centraliza la lógica de agregar y renovar el token, eliminando la duplicación de código en cada solicitud. Todas las solicitudes pasan por un único interceptor que verifica el estado de la respuesta y renueva el token cuando es necesario sin intervención del desarrollador.