Português (Portugal)

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

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

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

Darcy Ye

Developer

1/3/2024

Pare de perder semanas com autenticação de utilizadores

Lance aplicações seguras mais rapidamente com o Logto. Integre a autenticação de utilizadores 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 usados no OAuth 2.0, permitindo uma autorização de utilizador segura e eficiente para aplicações web. Ambos os fluxos implementam um processo de autorização que permite que os utilizadores concedam acesso às aplicações sem expor diretamente as suas credenciais. O fluxo implícito foi inicialmente desenvolvido para abordar limitações do navegador, mas com o advento das tecnologias web modernas, o fluxo de código de autorização tornou-se a escolha preferida por muitos desenvolvedores devido às suas funcionalidades de segurança melhoradas.

Neste artigo, vamos explorar as diferenças entre estes dois tipos de concessão e explicar por que deves evitar usar o fluxo implícito em favor do fluxo de código de autorização.

O que é o OAuth 2.0?

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

Quando se fala em OAuth, geralmente referimos-nos ao OAuth 2.0, conhecido como "Authorization Aberta", é um protocolo estabelecido que permite que websites ou aplicações utilizem recursos de outros serviços web em nome de um utilizador. Sucedeu ao OAuth 1.0 em 2012 e desde então tornou-se o padrão amplamente aceite para autorização digital. O OAuth 2.0 é projetado para fornecer acesso controlado aos utilizadores, permitindo que aplicações cliente tenham permissões específicas para interagir com recursos que representam o utilizador, tudo isso sem revelar os detalhes de login do utilizador.

Embora seja primordialmente utilizado em ambientes web, a estrutura do OAuth 2.0 também se estende a várias formas de clientes. Isto inclui aplicações baseadas em navegador, aplicações web do lado do servidor, aplicações nativas ou móveis e até dispositivos interconectados, detalhando a abordagem para gerir o acesso delegado em todas estas plataformas. Introduz o conceito de "tipos de concessão" para definir o processo de autorização entre a aplicação cliente, o utilizador e o servidor de autorização. Estes tipos de concessão são usados para determinar como a aplicação cliente pode obter um token de acesso para acessar os recursos do utilizador. Os tipos de concessão mais comuns no OAuth 2.0 são:

Código de autorização: Ideal para todos os tipos de aplicações, especialmente para aplicações web do lado do servidor, onde a aplicação cliente pode trocar um código de autorização por um token de acesso e gerir tokens de forma segura.
Implícito: Um fluxo simplificado, projetado para aplicações baseadas em navegador, sem um componente de servidor seguro. Foi criado para entregar rapidamente tokens para as aplicações cliente. Mas agora é amplamente desaprovado devido a preocupações de segurança.
Credenciais de senha do proprietário do recurso: Este tipo permite que a aplicação cliente solicite e receba diretamente um token de acesso, submetendo as credenciais do utilizador (nome de utilizador e senha). Devido ao facto de a aplicação cliente ter acesso direto às credenciais do utilizador, este tipo de concessão também é considerado como desaprovado e deve ser evitado em todas as circunstâncias.
Credenciais do cliente: Usado para comunicação máquina a máquina onde a própria aplicação é o cliente. Envolve a aplicação 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 de OAuth 2.0 onde o token de acesso é retornado diretamente para o cliente no URI de redirecionamento, sem um passo adicional para trocar um código de autorização por um token. Foi originalmente projetado para aplicações web que não podiam fazer solicitações do lado do servidor para o endpoint do token devido a restrições do navegador.

Como funciona o fluxo implícito?

O utilizador clica num botão ou link na aplicação cliente para iniciar o processo de autenticação.
A aplicação cliente redireciona o utilizador para o servidor de autorização para autenticar, incluindo o âmbito de acesso desejado.
O servidor de autorização solicita aos utilizadores que façam login e concedam permissão à aplicação cliente.
Após autenticação e autorização bem-sucedidas, o servidor de autorização redireciona o navegador do utilizador de volta para o URI de redirecionamento especificado do cliente, com o token de acesso incluído no fragmento do URL.
A aplicação cliente extrai o token de acesso do fragmento do URL e o utiliza para aceder aos recursos do utilizador no servidor de recursos.

Riscos de segurança com o fluxo implícito

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

Exposição do token: O token de acesso é retornado diretamente para o cliente no fragmento do URL, o que pode ser facilmente interceptado por partes maliciosas. Isto 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 websites maliciosos podem enganar usuários a concederem acesso não autorizado às suas contas.

Devido a estas 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 utilizador segura.

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

O fluxo de código de autorização, por outro lado, é um fluxo OAuth 2.0 mais seguro que separa o processo de autorização em dois passos: a aplicação 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 aplicações web do lado do servidor que podem armazenar com segurança as credenciais do cliente e gerir tokens de acesso. Com a introdução da extensão PKCE, o fluxo de código de autorização pode agora ser usado em aplicações baseadas em navegador também.

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

O utilizador clica num botão ou link na aplicação cliente para iniciar o processo de autenticação.
A aplicação cliente redireciona o utilizador para o servidor de autorização para autenticar com o âmbito de acesso desejado.
O servidor de autorização solicita ao utilizador que faça login e conceda permissão à aplicação cliente.
Após autenticação e autorização bem-sucedidas, o servidor de autorização retorna um código de autorização ao cliente.
A aplicação cliente troca com segurança o código de autorização por um token de acesso, fazendo uma solicitação de servidor para servidor para o endpoint do token usando suas credenciais de cliente.
O servidor de autorização valida o código de autorização e credenciais do cliente e retorna um token de acesso ao cliente.
A aplicação cliente usa o token de acesso para acessar os recursos do utilizador no servidor de recursos.

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

O utilizador clica num botão ou link na aplicação cliente para iniciar o processo de autenticação.
A aplicação cliente gera um verificador de código e um desafio de código.
A aplicação cliente redireciona o utilizador 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 posterior verificação.
O utilizador autentica e aprova o acesso à aplicação cliente.
O servidor de autorização retorna um código de autorização ao cliente.
A aplicação cliente troca o código de autorização por um token de acesso, fazendo uma solicitação de servidor para servidor ao endpoint do 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 ao cliente.
A aplicação cliente usa o token de acesso para acessar os recursos do utilizador no servidor de recursos.

Saiba mais sobre o PKCE fluxo.