OAuth para clientes públicos: o fluxo moderno que deve passar nos testes
RFC 9700 tornou explícita a linha de base atual: authorization code, PKCE para clientes públicos, correspondência exata de redirect URI, proteção contra mix-up e abandono do implicit e do password grant.
- Natureza
- Baseline de engenharia baseado em RFCs publicadas
- Quem deve ler
- Arquitetura, desenvolvimento, segurança de aplicações, IAM e QA
- Publicado e verificado
- 4 de agosto de 2026
- Limite
- O perfil final depende do tipo de cliente, servidor de autorização, recursos e modelo de ameaça
Em resumo
Aplicações nativas e frontends no browser não conseguem manter um client secret como segredo; a segurança tem de nascer do fluxo. O cliente cria um verifier único e envia apenas o challenge, liga a resposta à transação, valida o issuer correto e troca o code pelo canal previsto. PAR reduz a superfície do pedido no browser; DPoP pode restringir tokens ao detentor de uma chave; audiência e âmbito limitam onde e para quê o token vale. A matriz abaixo transforma normas em critérios de aceitação testáveis.
- Clientes públicos devem usar PKCE; S256 é a transformação a exigir quando suportada.
- O implicit grant expõe tokens no endpoint de autorização e deixou de ser a opção recomendada; use response type code.
- O resource owner password credentials grant não deve ser usado.
- PKCE não substitui todas as verificações: redirect URI, issuer, state ou nonce, audiência e políticas de token continuam a importar.
O desenho seguro remove segredos falsos e liga cada resposta à transação certa
Um segredo empacotado numa aplicação nativa ou entregue ao browser pode ser extraído; não o use como prova de identidade do cliente público. PKCE cria prova por transação: o cliente guarda o verifier, envia o challenge e só quem apresenta o verifier correspondente consegue trocar o code.
Quando o cliente conversa com mais de um authorization server, valide o issuer da resposta ou use uma contramedida equivalente. A comparação exata do redirect URI reduz fuga de codes; state ou proteção equivalente liga a resposta à sessão; nonce protege propriedades específicas em OpenID Connect.
Fluxo de autorização com verificações explícitas
- 1Criar transação
Gerar verifier, challenge S256, state e, quando aplicável, nonce únicos.
- 2Enviar pedido
Usar browser externo e redirect URI pré-registado; PAR quando o perfil o exigir.
- 3Validar retorno
Comparar state, issuer, redirect e contexto antes de aceitar o code.
- 4Trocar code
Apresentar verifier no token endpoint correto e rejeitar reutilização ou divergência.
- 5Usar token limitado
Validar audiência, âmbito, expiração e prova DPoP quando adotada.
Cada controlo precisa de um teste negativo, não apenas de configuração
Teste o que o sistema rejeita. Um fluxo feliz confirma interoperabilidade; não confirma que um code roubado, um issuer trocado ou um redirect quase igual falha de forma segura.
Ameaça, controlo e critério de aceitação
| Ameaça | Controlo | Teste negativo | Aceitação |
|---|---|---|---|
| Interceção do code | PKCE S256 | Trocar code sem verifier ou com outro | Falha sem emitir token |
| Mix-up de servidor | Validação de iss | Resposta com issuer diferente | Cliente rejeita antes da troca |
| Fuga por redirect | Correspondência exata | Alterar path, host ou query | Pedido ou retorno rejeitado |
| Pedido manipulado | PAR | Alterar parâmetros no browser | Servidor usa o pedido empurrado |
| Replay de token | DPoP quando aplicável | Usar token sem chave ou noutra origem | Recurso rejeita a prova |
| Privilégio excessivo | Audiência e âmbito | Usar token noutro recurso ou ação | Recurso recusa |
O release gate deve provar cliente, servidor e recurso como um sistema
Automatize os testes contra a configuração real do authorization server e um resource server representativo. Valide também logs: não devem guardar code, verifier, token ou parâmetros sensíveis completos. A rotação e a revogação devem funcionar sem reinstalar toda a aplicação.
PAR e DPoP resolvem classes específicas de ameaça; não os trate como selos universais. DPoP perde valor se token e chave forem ambos roubados do mesmo contexto comprometido. A decisão deve partir do atacante real e do custo operacional do mecanismo.
- Recusar implicit e password grant em novos clientes.
- Usar browser externo em aplicações nativas, não um webview embebido.
- Manter allowlist exata de redirects por ambiente.
- Testar expiração, refresh rotation, revogação, logout e relógio desalinhado.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01RFC 9700 — Best Current Practice for OAuth 2.0 SecurityRFC Editor · SYS-RFC
- 02RFC 7636 — Proof Key for Code ExchangeRFC Editor · SYS-RFC
- 03RFC 9126 — Pushed Authorization RequestsRFC Editor · SYS-RFC
- 04RFC 9207 — Authorization Server Issuer IdentificationRFC Editor · SYS-RFC
- 05RFC 9449 — Demonstrating Proof of PossessionRFC Editor · SYS-RFC
- 06RFC 8252 — OAuth 2.0 for Native AppsRFC Editor · SYS-RFC
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.