Session Token no desenvolvimento de aplicações — o que é, princípio de funcionamento e diferenças do JWT

O que é um Session Token?

Session Token (identificador de sessão) é uma string única que o servidor gera e associa aos dados da sessão após a autenticação do utilizador. O token não contém qualquer informação do utilizador — é simplesmente uma chave para os dados armazenados no servidor. Esta abordagem chama-se autenticação stateful: o servidor armazena o estado de cada sessão ativa e verifica-o em cada pedido.

Os dados da sessão incluem: identificador do utilizador, hora de início de sessão, endereço IP, user-agent, lista de permissões, hora da última atividade. Quando o cliente envia um pedido com um session token, o servidor encontra o registo correspondente no armazenamento de sessões, verifica a sua validade e recupera os dados para processar o pedido. Se o registo da sessão estiver ausente ou tiver expirado, o servidor devolve um erro de autenticação e requer um novo início de sessão.

Segundo OWASP, 2025, o session token continua a ser o padrão para aplicações que requerem revogação imediata do acesso — por exemplo, em sistemas bancários e portais corporativos onde um administrador deve poder terminar a sessão de um utilizador instantaneamente. Nestes sistemas, o session token proporciona um controlo total sobre o acesso que é inatingível para tokens stateless sem mecanismos de bloqueio adicionais.

Como funciona um Session Token

O processo começa quando o cliente envia as credenciais para o servidor de autenticação. O servidor verifica o utilizador e a palavra-passe, cria um registo de sessão no armazenamento (geralmente Redis ou base de dados) e devolve um session token único ao cliente. O cliente guarda o token e envia-o com cada pedido subsequente, e o servidor verifica a existência e validade da sessão de cada vez.

Sessão do servidor e armazenamento

Redis é o armazenamento de sessões mais popular graças ao armazenamento em memória e ao suporte de TTL (time-to-live). Cada sessão é armazenada como um par chave-valor, onde a chave é o session token e o valor é um objeto JSON com os dados da sessão. O TTL remove automaticamente as sessões expiradas. Alternativas: Memcached (apenas memória, sem persistência em disco), PostgreSQL/MySQL (persistentes mas mais lentos) e DynamoDB (para infraestrutura AWS).

Exemplo de estrutura de sessão em Redis: session:{token} → {“userId”: 42, “role”: “admin”, “createdAt”: 1812345678, “lastAccess”: 1812345678}. O servidor atualiza o lastAccess em cada pedido, o que permite implementar um timeout de inatividade — terminação automática da sessão após um período sem atividade.

Cookie vs Cabeçalho

Session Token pode ser transmitido de duas formas: através de um cookie HTTP ou através do cabeçalho HTTP Authorization. Os cookies são o método tradicional para aplicações web: o servidor define um cookie com as flags HttpOnly (inacessível a JavaScript), Secure (apenas HTTPS) e SameSite (proteção contra CSRF). Para aplicações móveis, é mais comum usar o cabeçalho Authorization: Bearer <session_token>, já que o mecanismo de cookies nem sempre é conveniente em clientes nativos.

Ciclo de vida do Session Token

O ciclo de vida do session token inclui três etapas: criação, manutenção da sessão ativa e terminação. Cada etapa requer uma configuração de segurança adequada para evitar a fuga ou interceção do token.

Criação, armazenamento e eliminação

Criação — o servidor gera uma string aleatória criptograficamente segura de 128–256 bits (por exemplo, através de SecureRandom em Java ou os.urandom em Python). O token deve ser imprevisível — o uso de UUID ou timestamp sem entropia não é aceitável. Armazenamento no cliente: em iOS — Keychain, em Android — EncryptedSharedPreferences, na web — cookie HttpOnly. Eliminação ocorre no logout: o cliente remove o token do armazenamento, o servidor elimina o registo da sessão do Redis. Após o logout, o session token torna-se inútil — o servidor não encontrará um registo correspondente.

Segundo SANS Institute, 2025, a implementação correta da terminação de sessão (logout com limpeza no servidor) previne até 70% dos ataques com tokens roubados. É crítico não apenas eliminar o token no cliente, mas também invalidar a sessão no servidor.

Session Token vs JWT

Session Token e JWT representam duas abordagens diferentes para a autenticação. Session Token é stateful (o servidor armazena o estado), JWT é stateless (os dados dentro do token). A escolha entre eles depende da arquitetura da aplicação e dos requisitos de segurança.

Quando escolher Session Token

Session Token é preferível quando: é necessária revogação instantânea de sessões (banca, painéis de administração), a aplicação funciona num ou vários servidores com Redis partilhado, os dados da sessão são grandes e não cabem no JWT, ou a equipa quer minimizar o risco de fuga de dados através da descodificação do token. Nestes cenários, o session token proporciona um bloqueio imediato do acesso perante atividade suspeita — basta eliminar um registo do Redis para que todas as sessões do utilizador se tornem inválidas.

Segundo Redis, 2025, o uso de TTL ao nível das chaves de sessão (comando EXPIRE) limpa automaticamente as sessões expiradas sem sobrecarga em tarefas de fundo. Para sessões com TTL de 1 hora e uma carga de 10 000 utilizadores simultâneos, o Redis consome cerca de 1 GB de RAM com um tamanho de sessão de 1 KB, tornando-o economicamente eficiente para a maioria das aplicações.

Segurança do Session Token

A segurança do session token baseia-se em dois princípios: o token deve ser imprevisível e protegido durante a transmissão e armazenamento. As principais ameaças são a interceção do token (man-in-the-middle, XSS), a sua previsão (geração fraca) e a fixação de sessão (session fixation).

Proteção contra roubo do token

A proteção inclui: uso de HTTPS para todos os pedidos com token, definição de um TTL curto de sessão (15–60 minutos de inatividade), vinculação da sessão ao IP e user-agent (verificação adicional em cada pedido), uso das flags Secure e HttpOnly para cookies, e rotação periódica do session token após operações sensíveis (mudança de palavra-passe, escalada de privilégios). A OWASP recomenda também implementar Gestão de Sessões com invalidação da sessão antiga ao criar uma nova após o início de sessão — isto previne a fixação de sessão.

Segundo OWASP ASVS, 2025, uma sessão deve estar vinculada a pelo menos dois fatores: o próprio token (o que o cliente tem) e o IP/user-agent (o que o servidor sabe). Se estes fatores não coincidirem, o servidor deve terminar a sessão e solicitar uma nova autenticação.

Exemplo de implementação em Kotlin

Abaixo está um exemplo de implementação de session token no servidor em Kotlin usando Spring Boot e Redis. O servidor gera um token criptograficamente seguro através de SecureRandom, guarda a sessão em Redis com TTL e verifica-a em cada pedido. O código demonstra três operações principais: criação de sessão, validação e invalidação.

data class Session(
    val userId: Long,
    val role: String,
    val createdAt: Long,
    val lastAccess: Long
)

object SessionManager {
    private val redis = JedisPool("localhost", 6379)

    fun createSession(userId: Long, role: String): String {
        val token = generateSecureToken()
        val session = Session(userId, role, now(), now())
        redis.resource.use { conn ->
            conn.setex("session:$token", 3600, toJson(session))
        }
        return token
    }

    fun validateSession(token: String): Session? {
        redis.resource.use { conn ->
            val json = conn.get("session:$token") ?: return null
            return fromJson(json)
        }
    }

    fun invalidateSession(token: String) {
        redis.resource.use { it.del("session:$token") }
    }

    private fun generateSecureToken(): String {
        val bytes = ByteArray(32)
        SecureRandom().nextBytes(bytes)
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)
    }
}

Esta implementação utiliza JedisPool para uma conexão thread-safe ao Redis. O método createSession define um TTL de 1 hora (3600 segundos) — após este período, o Redis eliminará automaticamente o registo. O método validateSession devolve null para sessões inexistentes ou expiradas, permitindo ao servidor tratar corretamente um pedido com um token inválido e devolver HTTP 401.