Autenticação em apps Delphi: trate tokens como credenciais, não como strings comuns

Uma string de token parece um detalhe da chamada HTTP. Na prática, ela pode permitir acesso a dados e operações. Se aparecer em logs, num arquivo de configuração distribuído ou em uma URL, o aplicativo criou mais cópias de uma credencial do que o fluxo precisava.

Antes de escolher onde guardar o token, entenda quem o emite, quais permissões ele representa, quanto tempo dura e como o servidor verifica seu uso.

Um aplicativo distribuído não guarda segredos como um servidor

Código e recursos enviados ao dispositivo podem ser inspecionados. Esconder um client_secret no executável ou ofuscar uma constante não cria a mesma fronteira de segurança de um backend sob seu controle.

Para OAuth em aplicativos nativos, a recomendação é realizar a autorização por um agente externo, como o navegador, e usar PKCE em clientes públicos. Isso evita que o próprio aplicativo hospede uma tela capaz de observar as credenciais do usuário. RFC 8252.

OAuth é uma estrutura de autorização. Se o objetivo é identificar o usuário, o protocolo e o provedor podem usar OpenID Connect, com regras adicionais. Não interprete qualquer resposta OAuth como prova completa de autenticação da pessoa.

Entenda o que PKCE protege

PKCE vincula a autorização iniciada pelo cliente à troca do código por tokens. O cliente gera um verificador, envia um desafio derivado e depois comprova o verificador na troca. A orientação atual recomenda métodos que não exponham esse verificador na requisição, como S256. RFC 9700.

Esse mecanismo não substitui a validação do retorno, o registro correto da URI de redirecionamento ou a política do provedor. Use uma biblioteca e um fluxo compatíveis, em vez de montar uma solução pela junção de snippets incompletos.

Uma boa implementação também distingue o início de uma nova autorização de um retorno inesperado. Defina como o estado da operação é validado e como erros ou cancelamento voltam à interface.

Separe os estados que a tela apresenta

Sem sessão → Autorização em andamento → Sessão disponível
                    ↓                         ↓
              Cancelamento/erro        Expiração/revogação

Evite usar apenas um booleano Logado para toda essa informação. O token pode estar disponível e já ter expirado. A rede pode falhar durante uma renovação. O usuário pode revogar o acesso fora do aplicativo.

Não exiba uma falha de conexão como se a senha estivesse errada. Essa mensagem deve corresponder ao que o sistema realmente sabe.

Armazenamento e envio são fronteiras diferentes

Use o mecanismo protegido apropriado à plataforma, como o armazenamento de credenciais do sistema, por meio de uma integração confiável. Verifique comportamento com backup, reinstalação e troca de usuário. Criptografar um arquivo com uma chave distribuída ao lado dele não resolve a extração do segredo.

Quando o serviço utiliza bearer tokens, siga seu contrato de envio e preserve HTTPS com validação de certificados. Não passe a credencial na URL por conveniência: URLs circulam por histórico, logs e infraestrutura.

O exemplo abaixo é apenas a forma de um cabeçalho, não uma credencial utilizável:

Authorization: Bearer <token de acesso obtido pelo fluxo autorizado>

Remova esse campo de logs, relatórios de erro e capturas compartilhadas. Dados pessoais no corpo também precisam de tratamento.

Autorize a operação no servidor

Ocultar um botão ou checar o perfil localmente melhora a apresentação, mas não autoriza uma operação. O servidor deve validar a credencial e verificar se a identidade pode acessar o recurso solicitado.

Também não trate um JWT simplesmente decodificado como verificado. A checagem depende de assinatura, emissor, público, validade e demais requisitos do protocolo adotado. O cliente não deve substituir o servidor nessa decisão.

Roteiro de avaliação

Com um provedor de testes, percorra autorização concluída, cancelada, retorno inválido, token expirado, acesso revogado e falha de renovação. Confira o que acontece no logout e quais dados locais precisam ser removidos.

Não foi implementada nem testada uma integração completa de identidade neste artigo. O objetivo é orientar o desenho das fronteiras. Para conectar esse fluxo ao isolamento web, leia Isolamento de dados no UniGUI.

Fluxo conceitual OAuth com PKCE

Aplicativo → verifier/challenge → navegador de autorização → callback validado → código + verifier → token → recurso → renovação/encerramento.

1. Registre tipo de aplicativo e URI permitida no provedor de teste.
2. Gere valores imprevisíveis por operação e valide state.
3. Use navegador de autorização; não capture a senha na aplicação.
4. Diferencie recusa, expiração e falha de transporte.
5. Defina armazenamento protegido e descarte no logout, sem tokens em logs/URLs.

Checklist por plataforma: callback desktop; retorno ao app e armazenamento mobile; segredo e sessão no servidor web. Fluxo conceitual: nenhum provedor, credencial ou token usado nesta entrega. Confira documentação do provedor antes de aplicar.