Português (Brasil)

oauth
fluxo implícito
código de autorização
PKCE

Fluxo implícito vs. Fluxo de código de autorização: Por que o fluxo implícito está morto?

Por que existe um "Fluxo de código de autorização" no OAuth 2.0 quando já temos o "Fluxo implícito"? Vamos mergulhar nos detalhes desses dois tipos de concessão e descobrir por que você deve evitar usar o fluxo implícito.

Darcy Ye

Developer

1/3/2024

Pare de perder semanas com autenticação de usuários

Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.

Começar

O Fluxo de código de autorização e o Fluxo implícito são dois dos tipos de concessão mais comumente usados no OAuth 2.0, permitindo uma autorização de usuário segura e eficiente para aplicações web. Ambos os fluxos implementam um processo de autorização que permite que os usuários concedam acesso a aplicativos sem expor suas credenciais diretamente. O fluxo implícito foi inicialmente desenvolvido para lidar com limitações dos navegadores, mas, com o advento das tecnologias modernas da web, o fluxo de código de autorização se tornou a escolha preferida para muitos desenvolvedores devido aos seus recursos aprimorados de segurança.

Neste artigo, exploraremos as diferenças entre esses dois tipos de concessão e explicaremos por que você deve evitar usar o fluxo implícito em favor do fluxo de código de autorização.

O que é OAuth 2.0?

Antes de mergulharmos nos detalhes desses dois tipos de concessão, vamos primeiro entender o que é OAuth 2.0 e por que é essencial para aplicações web modernas.

Quando falamos sobre OAuth, geralmente nos referimos ao OAuth 2.0, conhecido como "Open Authorization", é um protocolo estabelecido que permite que sites ou aplicativos utilizem recursos de outros serviços web em nome de um usuário. Ele substituiu o OAuth 1.0 em 2012 e desde então se tornou o padrão amplamente aceito para autorização digital. O OAuth 2.0 foi projetado para fornecer acesso controlado aos usuários, permitindo que aplicativos cliente tenham permissões específicas para interagir com recursos que representam o usuário, tudo sem revelar os detalhes de login do usuário.

Embora utilizado principalmente em ambientes web, a estrutura do OAuth 2.0 também se estende a várias formas de cliente. Isso inclui aplicativos baseados em navegador, aplicativos web do lado do servidor, aplicativos nativos ou móveis e até dispositivos interconectados, detalhando a abordagem para gerenciamento de acesso delegado nessas plataformas. Introduz o conceito de "tipos de concessão" para definir o processo de autorização entre o aplicativo cliente, o usuário e o servidor de autorização. Esses tipos de concessão são usados para determinar como o aplicativo cliente pode obter um token de acesso para acessar os recursos do usuário. Os tipos de concessão mais comuns no OAuth 2.0 são:

Código de autorização: Ideal para todos os tipos de aplicativos, especialmente aplicativos web do lado do servidor, onde o aplicativo cliente pode trocar um código de autorização por um token de acesso e gerenciar tokens com segurança.
Implícito: Um fluxo simplificado, projetado para aplicações baseadas em navegador, sem um componente servidor seguro. Foi criado para entregar rapidamente tokens aos aplicativos cliente. Mas agora é amplamente descontinuado devido a problemas de segurança.
Credenciais de senha do proprietário do recurso: Este tipo permite que o aplicativo cliente solicite e receba diretamente um token de acesso submetendo as credenciais do usuário (nome de usuário e senha). Pelo fato de o aplicativo cliente ter acesso direto às credenciais do usuário, esse tipo de concessão também é considerado como descontinuado e deve ser evitado em todas as circunstâncias.
Credenciais do cliente: Usado para comunicação máquina a máquina onde o próprio aplicativo é o cliente. Envolve o aplicativo autenticando-se com o servidor de autorização e solicitando um token de acesso para acessar seus próprios recursos ou os de outro serviço.

O que é o fluxo implícito?

O fluxo implícito é um fluxo simplificado do OAuth 2.0 em que o token de acesso é retornado diretamente para o cliente no URI de redirecionamento, sem uma etapa adicional para trocar um código de autorização por um token. Ele foi originalmente projetado para aplicativos web que não podiam fazer requisições do lado do servidor para o endpoint de token devido a restrições do navegador.

Como o fluxo implícito funciona?

O usuário clica em um botão ou link no aplicativo cliente para iniciar o processo de autenticação.
O aplicativo cliente redireciona o usuário para o servidor de autorização para autenticar, incluindo o escopo desejado de acesso.
O servidor de autorização solicita que os usuários façam login e concedam permissão para o aplicativo cliente.
Após a autenticação e autorização bem-sucedidas, o servidor de autorização redireciona o navegador do usuário de volta para o URI de redirecionamento especificado do cliente, com o token de acesso incluído no fragmento URL.
O aplicativo cliente extrai o token de acesso do fragmento URL e o usa para acessar os recursos do usuário no servidor de recursos.

Riscos de segurança com o fluxo implícito

O fluxo implícito tem várias vulnerabilidades de segurança:

Exposição do token: O token de acesso é retornado diretamente para o cliente no fragmento URL, o que pode ser facilmente interceptado por partes mal-intencionadas. Isso expõe o token de acesso a roubo e uso indevido potenciais.
Ataques CSRF: O fluxo implícito é suscetível a ataques de Cross-Site Request Forgery (CSRF), onde sites maliciosos podem enganar os usuários para conceder acesso não autorizado às suas contas.

Devido a essas preocupações de segurança, o fluxo implícito não é mais recomendado para aplicações web modernas. Em vez disso, o fluxo de código de autorização com PKCE (Proof Key for Code Exchange) é a escolha preferida para uma autorização de usuário segura.

O que é o fluxo de código de autorização?

O fluxo de código de autorização, por outro lado, é um fluxo mais seguro do OAuth 2.0 que separa o processo de autorização em duas etapas: o aplicativo cliente primeiro obtém um código de autorização do servidor de autorização, e depois troca o código por um token de acesso. Este fluxo foi inicialmente projetado para aplicativos web do lado do servidor que podem armazenar com segurança credenciais de cliente e gerenciar tokens de acesso. Com a introdução da extensão PKCE, o fluxo de código de autorização agora pode ser usado em aplicativos baseados em navegador também.

Como o fluxo de código de autorização funciona para clientes privados com componente do lado do servidor?

O usuário clica em um botão ou link no aplicativo cliente para iniciar o processo de autenticação.
O aplicativo cliente redireciona o usuário para o servidor de autorização para autenticar com o escopo desejado de acesso.
O servidor de autorização solicita que os usuários façam login e concedam permissão para o aplicativo cliente.
Após a autenticação e autorização bem-sucedidas, o servidor de autorização retorna um código de autorização para o cliente.
O aplicativo cliente troca de forma segura o código de autorização por um token de acesso fazendo uma requisição de servidor para servidor ao endpoint de token usando suas credenciais de cliente.
O servidor de autorização valida o código de autorização e as credenciais de cliente e retorna um token de acesso para o cliente.
O aplicativo cliente usa o token de acesso para acessar os recursos do usuário no servidor de recursos.

Como o fluxo de código de autorização funciona para clientes públicos com PKCE?

O usuário clica em um botão ou link no aplicativo cliente para iniciar o processo de autenticação.
O aplicativo cliente gera um verificador de código e um desafio de código.
O aplicativo cliente redireciona o usuário para o servidor de autorização para autenticar com o desafio de código.
O servidor de autorização armazena o desafio de código para verificação posterior.
O usuário autentica e aprova o acesso ao aplicativo cliente.
O servidor de autorização retorna um código de autorização para o cliente.
O aplicativo cliente troca o código de autorização por um token de acesso fazendo uma requisição de servidor para servidor ao endpoint de token usando o verificador de código.
O servidor de autorização valida o código de autorização e o verificador de código em relação ao desafio de código armazenado.
O servidor de autorização retorna um token de acesso para o cliente.
O aplicativo cliente usa o token de acesso para acessar os recursos do usuário no servidor de recursos.

Saiba mais sobre o fluxo PKCE.