Fluxos do OAuth 2.0

OAuth 2.0 é uma estrutura de autorização delegada. Ele permite que um usuário conceda a um aplicativo de terceiros acesso limitado aos seus recursos em outro serviço sem compartilhar sua senha.

• Ele trata de autorização (o que um aplicativo pode fazer), não de autenticação (quem é o usuário).
• O aplicativo recebe um access_token com escopo limitado, nunca as credenciais do usuário.

Os defensores devem lembrar-se: o OAuth, por si só, não comprova a identidade. Tratar um token de acesso como prova de login é um erro clássico abordado pelo OIDC.

Todo fluxo OAuth envolve quatro funções. Mapeá-las corretamente é essencial para a modelagem de ameaças.

• Proprietário dos recursos — o usuário que possui os dados.
• Cliente — o aplicativo que solicita acesso.
• Servidor de autorização (AS) — emite tokens após o consentimento.
• Servidor de recursos (RS) — a API que armazena dados protegidos e valida tokens.

Os limites de confiança ficam entre essas funções. Um cliente comprometido ou um AS permissivo compromete toda a cadeia.

A concessão de código de autorização é o fluxo recomendado para aplicativos web e móveis. Ela separa o redirecionamento voltado ao usuário da troca secreta de tokens.

• O usuário é redirecionado ao AS para se autenticar e dar consentimento.
• O AS devolve um code de curta duração ao URI de redirecionamento registrado.
• O cliente troca o código, no lado do servidor, por tokens através de um canal de retorno.

Como os tokens são obtidos pelo canal de retorno, eles nunca aparecem na barra de endereço ou no histórico do navegador.

O PKCE (RFC 7636) reforça a concessão de código de autorização e agora é recomendado para todos os clientes, inclusive os confidenciais.

• O cliente gera um code_verifier aleatório e envia seu hash como code_challenge.
• Na troca do token, ele deve apresentar o verificador original.

Isso vincula o código ao solicitante original, impedindo que um invasor que intercepte o código de autorização o resgate.

A concessão de credenciais do cliente destina-se ao acesso de máquina para máquina, quando nenhum usuário está envolvido (um serviço de back-end chamando uma API).

• O cliente se autentica com suas próprias credenciais e recebe um token de acesso.
• Normalmente, não há consentimento do usuário nem token de atualização.

Restrinja rigorosamente o escopo desses tokens e faça a rotação dos segredos do cliente. Nunca use esse fluxo para personificar usuários finais.

O OAuth emite dois tipos principais de token, com durações e regras de tratamento muito diferentes.

• Token de acesso — de curta duração, enviado ao servidor de recursos em cada chamada. Trate-o como uma credencial de portador.
• Token de atualização — de longa duração, usado somente contra o AS para obter novos tokens de acesso.

Os tokens de atualização têm alto valor. Armazene-os com segurança, vincule-os ao cliente e ofereça suporte à revogação.

A maioria dos tokens de acesso do OAuth é composta por tokens de portador: quem detém o token pode usá-lo, assim como dinheiro em espécie.

• Sempre transmita por TLS; nunca em URLs, onde eles vazam para registros e referenciadores.
• Envie por meio do cabeçalho Authorization.
• Considere tokens vinculados ao remetente (DPoP, mTLS) para APIs de alto risco.

A concessão implícita legada retornava tokens diretamente no fragmento do URI de redirecionamento. Ela agora é desaconselhada pelo BCP de Segurança do OAuth 2.0 e foi removida no OAuth 2.1.

• Os tokens vazavam pelo histórico do navegador, pelos cabeçalhos de referenciador e pelos registros.
• A ausência de um canal de retorno resultava em uma autenticação mais fraca do cliente.

Em vez disso, use Código de autorização com PKCE para SPAs.

O parâmetro state protege a etapa de redirecionamento contra CSRF. O cliente gera um valor aleatório, armazena-o na sessão e o verifica no retorno de chamada.

• Se o state retornado não corresponder, rejeite a resposta.
• Isso impede que um invasor injete seu próprio código de autorização na sessão de uma vítima.

Escopos expressam a granularidade do acesso concedido por um token. Aplique o privilégio mínimo em todas as etapas.

• Solicite apenas os escopos de que a funcionalidade precisa (read:profile, não admin).
• Os servidores de recursos devem impor o escopo em cada ponto de acesso, não apenas confiar em um token válido.

O consentimento amplo demais é um risco comum no mundo real: os usuários aprovam aplicativos que solicitam muito mais do que o necessário.

A maioria dos incidentes do OAuth decorre da configuração, não do próprio protocolo.

• Redirecionamento aberto / correspondência flexível de redirect_uri permite que invasores roubem códigos.
• A ausência de state ou PKCE permite CSRF e injeção de códigos.
• Tokens de acesso de longa duração sem revogação.
• Tratar um token de acesso como uma asserção de autenticação.

Registre URIs de redirecionamento exatas e valide-as rigorosamente.

Escolha o fluxo correto e moderno para o cenário abaixo.

Principais conclusões:

• O OAuth 2.0 é autorização delegada, não autenticação.
• Quatro funções: proprietário do recurso, cliente, servidor de autorização e servidor de recursos.
• Código de autorização + PKCE é o padrão para a Web, dispositivos móveis e SPAs.
• Credenciais do cliente abrangem o acesso entre máquinas.
• Proteja-o com state, correspondência rigorosa de URIs de redirecionamento, tokens de acesso de curta duração e TLS em toda parte.
• As concessões implícita e de senha estão obsoletas.