Access Token no desenvolvimento iOS e Android — conceitos-chave, tipos de token e como funciona

O que é um Access Token?

Access Token — é uma string que um cliente (aplicativo mobile, SPA, servidor) usa para autenticar requisições HTTP a endpoints de API protegidos. O token é emitido pelo servidor de autorização após o usuário confirmar sua identidade e conceder ao aplicativo as permissões apropriadas (scope).

O access token é um elemento central do protocolo OAuth 2.0 e de todos os sistemas construídos sobre ele — OpenID Connect, Firebase Authentication, Auth0, Keycloak. Sem um access token, nenhuma requisição a uma API protegida será processada: o servidor retorna HTTP 401 Unauthorized. O token não identifica o usuário diretamente — ele confirma que o cliente tem o direito de executar uma ação específica em nome do usuário (autorização), não quem é o usuário (autenticação).

De acordo com Okta, 2025, mais de 80% das APIs públicas usam o esquema Bearer com access token no cabeçalho Authorization, substituindo métodos de autenticação obsoletos — Basic Auth e API Key. O access token também é a base para autorização delegada — um modelo no qual o usuário concede a um aplicativo acesso limitado aos seus dados em outro serviço. Por exemplo, quando um aplicativo mobile de edição de fotos solicita acesso ao Google Drive via OAuth 2.0, o usuário vê uma tela de consentimento listando scopes específicos e, após confirmação, recebe um access token com essas permissões.

Como funciona um Access Token

Mecanismo do access token é baseado no esquema Bearer: o cliente adiciona o cabeçalho Authorization: Bearer <token> a cada requisição HTTP. O servidor de recursos (API) recebe o token, valida-o e determina quais recursos são acessíveis. A validação pode ocorrer de duas formas: localmente (para JWT) ou através de um endpoint de introspecção (para opaque tokens).

Esquema Bearer Token

Bearer token significa que qualquer pessoa que apresentar o token (bearer) obtém o acesso correspondente. Isso impõe altos requisitos de proteção do token durante a transmissão e armazenamento. O esquema Bearer não exige que o cliente prove criptograficamente a posse do token — basta transmiti-lo. Portanto, o HTTPS é obrigatório: sem criptografia de tráfego, um atacante pode interceptar o token e usá-lo imediatamente.

De acordo com Cloudflare, 2025, a interceptação de um Bearer token em uma conexão HTTP não segura ocorre em média dentro de 12 segundos após o envio da requisição. Usar HTTPS e um TTL curto do access token (15–30 minutos) reduz o risco a praticamente zero. Proteção adicional em nível de aplicação — verificação da origem da requisição via OAuth 2.0 Token Binding (RFC 8471): o cliente prova a posse da chave TLS vinculada ao token, tornando inútil o roubo do token por interceptação.

Tipos de Access Token

Access Token existe em dois formatos: opaque e JWT (autossuficiente). A escolha entre eles é uma das decisões arquitetônicas-chave ao projetar um sistema de autenticação.

Opaque vs JWT

Opaque token é preferível para sistemas que exigem revogação instantânea de acesso e verificação centralizada de direitos. JWT é para arquitetura de microsserviços onde desempenho e minimização de chamadas de rede são importantes. Muitos provedores (Auth0, Keycloak) suportam ambos os formatos e permitem configurar o tipo de token para cada cliente. A escolha entre opaque e JWT é um compromisso entre controle e desempenho: opaque dá controle total ao servidor, JWT fornece latência mínima.

Ciclo de vida do Access Token

Ciclo de vida de um access token consiste em quatro fases: emissão, transmissão, uso e expiração. Cada fase tem seus próprios requisitos de segurança e restrições de protocolo.

Expiração e renovação

Access Token tem um tempo de vida limitado — tipicamente 15–60 minutos. O valor expires_in é indicado na resposta do servidor de autorização ao emitir o token. Após esse tempo, o token se torna inválido e o cliente deve obter um novo através do mecanismo de refresh token. O cliente pode verificar a expiração de duas formas: pelo campo exp no JWT (localmente) ou pela resposta HTTP 401 (para opaque tokens).

De acordo com Auth0 Best Practices, 2025, o TTL ideal do access token para aplicativos mobile é de 15–30 minutos. Um TTL muito curto (menos de 5 minutos) cria carga excessiva no endpoint do token durante cada renovação — com 10.000 usuários e TTL de 5 minutos, o servidor recebe até 2.000 requisições de renovação por minuto em horários de pico. Um TTL muito longo (mais de 2 horas) aumenta a janela de ataque em caso de vazamento do token — um atacante pode usar o token comprometido por várias horas antes que o acesso seja bloqueado automaticamente.

Segurança do Access Token

Segurança do access token deve ser garantida em todas as etapas: durante o armazenamento no dispositivo, durante a transmissão pela rede e durante o processamento no servidor. A recomendação básica é nunca armazenar o access token em locais acessíveis a outros aplicativos ou processos.

Proteção durante armazenamento e transmissão

Em dispositivos mobile, o access token é armazenado: no iOS — no Keychain com o atributo kSecAttrAccessibleAfterFirstUnlock (o token fica acessível após o primeiro desbloqueio, mesmo se o dispositivo estiver bloqueado — para atualizações em segundo plano); no Android — em EncryptedSharedPreferences. O access token nunca deve ser salvo em NSUserDefaults, SharedPreferences, arquivos em armazenamento externo ou logs do aplicativo. Durante a transmissão — apenas HTTPS com TLS 1.3 ou 1.2. Para cada requisição de API, o access token deve ser enviado no cabeçalho Authorization: Bearer, não em parâmetros de URL (query string) — URLs acabam em logs de servidores e navegadores.

De acordo com OWASP Mobile Top 10, 2025, o armazenamento inadequado de tokens no dispositivo (M1: Improper Platform Usage) e a transmissão insegura de dados (M3: Insecure Communication) estão entre as três vulnerabilidades mobile mais comuns que levam ao comprometimento de contas. Uma medida adicional — usar certificate pinning para todas as requisições com access token: o cliente verifica o certificado do servidor não apenas através da cadeia CA padrão, mas também através de uma impressão digital do certificado previamente salva (SHA-256 fingerprint). Isso previne ataques man-in-the-middle mesmo com um CA comprometido.

Exemplo de código em Kotlin

Abaixo está um exemplo em Kotlin para Android, demonstrando o envio de uma requisição com access token no cabeçalho Authorization e o tratamento de 401 com renovação automática via refresh token. O OkHttp com um Interceptor personalizado é utilizado.

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}")
}

O exemplo mostra duas abordagens: usar OkHttp Interceptor para gerenciamento automático de tokens e envio direto via HttpURLConnection. O OkHttp Interceptor é preferível — ele centraliza a lógica de adicionar e renovar o token, eliminando duplicação de código em cada requisição. Todas as requisições passam por um único interceptor que verifica o status da resposta e renova o token quando necessário, sem intervenção do desenvolvedor.