OAuth 2.1 está aqui: O que você precisa saber

Introdução#

Desde que o OAuth 2.0 (RFC 6749) foi lançado em 2012, o mundo dos aplicativos web e móveis mudou bastante. As pessoas estão migrando dos desktops para dispositivos móveis, e as Aplicações de Página Única (SPAs) agora estão em alta. Também vimos surgir várias novas tecnologias e frameworks web. Com todas essas mudanças, os desafios de segurança também aumentaram. Para acompanhar as tecnologias web mais recentes, novos RFCs como o Proof Key for Code Exchange (PKCE) têm sido continuamente lançados para melhorar o OAuth 2.0. Tornou-se crucial agrupar todas as melhores práticas para as atuais exigências de segurança, e é por isso que o OAuth 2.1 está chegando.

No futuro OAuth 2.1, o Grupo de Trabalho OAuth tem como objetivo consolidar todas as melhores práticas e recomendações de segurança em um único documento. No Logto, seguimos as últimas normas e melhores práticas do OAuth. Neste artigo, vamos explorar as principais diferenças entre OAuth 2.0 e OAuth 2.1 e como elas foram adotadas no Logto.

PKCE agora é obrigatório para todos os clientes OAuth que utilizam o fluxo de Código de Autorização#

Uma das mudanças mais significativas no OAuth 2.1 é que o Proof Key for Code Exchange (PKCE) agora é obrigatório para todos os clientes OAuth que utilizam o fluxo de Código de Autorização. PKCE é uma extensão de segurança que previne ataques de interceptação de código de autorização. Isso é especialmente útil para aplicativos móveis e Aplicações de Página Única (SPAs), onde o segredo do cliente não pode ser armazenado de forma segura.

Os clientes OAuth podem ser categorizados em dois tipos diferentes com base em sua capacidade de armazenar segredos de forma segura:

1. Clientes confidenciais: Esses clientes podem armazenar segredos de forma segura, como aplicativos web renderizados no servidor e servidores web. Todas as solicitações relacionadas à autorização são feitas no lado do servidor, e o risco de exposição do segredo do cliente é baixo.

2. Clientes públicos: Esses clientes não podem armazenar segredos de forma segura, como aplicativos móveis e SPAs. O segredo do cliente pode ser facilmente extraído do código do lado do cliente, e é difícil protegê-lo de atacantes.

Para clientes públicos, o PKCE é uma medida de segurança indispensável. Ele garante que o código de autorização só possa ser trocado pelo cliente que iniciou a solicitação de autorização.

O PKCE funciona gerando um verificador de código aleatório e um desafio de código com base no verificador de código. O verificador de código é enviado ao servidor de autorização, e o desafio de código é usado para verificar o verificador de código ao trocar o código de autorização por um token de acesso.

No OAuth 2.1, o PKCE torna-se obrigatório para todos os clientes OAuth que empregam o fluxo de Código de Autorização, independentemente de seu status de confidencialidade—seja confidencial ou público. Esse ajuste fundamental garante proteção universal contra potenciais ataques de interceptação de código de autorização.

No Logto, o fluxo de validação PKCE é automaticamente ativado para ambos, clientes públicos e confidenciais.

Para SPAs e aplicativos móveis, o PKCE é uma medida de segurança indispensável para proteger o fluxo de Código de Autorização no Logto. Qualquer solicitação de autorização sem um desafio de código será prontamente recusada pelo servidor de autorização do Logto.

Em relação aos clientes confidenciais (aplicativos web tradicionais), para melhorar a compatibilidade com sistemas legados, o Logto ainda permite a omissão do desafio de código na solicitação de autorização. No entanto, nós recomendamos fortemente que clientes confidenciais adotem o PKCE ao incorporarem o desafio de código na solicitação de autorização, seguindo as práticas dos clientes públicos.

Correspondência exata de URIs de Redirecionamento#

Um URI de Redirecionamento (Uniform Resource Identifier) é um endpoint específico ou URL que o servidor de autorização redireciona o usuário após o processo de autenticação e autorização.

Durante o fluxo de OAuth, a aplicação cliente inclui um URI de Redirecionamento como parte da solicitação de autorização inicial. Após o usuário completar o processo de autenticação, o servidor de autorização gera uma resposta que inclui um Código de Autorização e redireciona o usuário de volta ao URI de Redirecionamento especificado. Qualquer desvio do URI de Redirecionamento original pode levar a um vazamento de código ou token.

A correspondência exata de URIs de Redirecionamento foi introduzida pela primeira vez na seção 4.1 das Melhores Práticas de Segurança de OAuth 2.0. Essa prática garante que o URI de Redirecionamento deve corresponder exatamente ao registrado com o servidor de autorização. Qualquer desvio do URI de Redirecionamento registrado resultará em uma resposta de erro.

Recebemos inúmeras solicitações da comunidade sobre a implementação de correspondência de curinga para URIs de Redirecionamento. Embora a correspondência de curinga possa oferecer conveniência para desenvolvedores que gerenciam múltiplos subdomínios ou caminhos, especialmente com um grande número de subdomínios aleatórios, ela também introduz riscos de segurança, como ataques de redirecionamento aberto. Para uma ilustração prática dos perigos causados pela falta de validação do URI de Redirecionamento, consulte nosso post no blog Um breve resumo da segurança OAuth.

Em linha com os rígidos padrões de segurança do OAuth 2.1, o Logto utiliza a correspondência exata de strings dos URIs de Redirecionamento. Essa decisão prioriza a segurança do fluxo de OAuth. Em vez de utilizar correspondência de curinga, incentivamos os desenvolvedores a registrarem todos os URIs de Redirecionamento potenciais no servidor de autorização do Logto. Isso garante uma validação completa dos URIs de Redirecionamento e ajuda a mitigar vulnerabilidades de segurança potenciais.

O Fluxo Implícito foi depreciado#

O fluxo de concessão implícita no OAuth 2.0 foi projetado para SPAs, onde o token de acesso é retornado diretamente no fragmento da URL após o usuário se autenticar. Esse método era conveniente porque evitava uma etapa adicional de troca de token, permitindo que o cliente recebesse o token diretamente.

No entanto, essa conveniência tem seus contratempos. O token de acesso pode ser exposto a partes não autorizadas através do histórico do navegador, cabeçalhos de referência ou outros meios, facilitando a ocorrência de brechas de segurança, especialmente quando os tokens de acesso permanecem válidos por longos períodos. Por exemplo, se a solicitação de autorização for interceptada por uma parte maliciosa, eles poderão facilmente extrair o token de acesso do fragmento da URL e se passar pelo usuário.

Nas Melhores Práticas de Segurança de OAuth 2.0, está claramente declarado que:

Clientes NÃO DEVEM usar a concessão implícita (tipo de resposta "token") ou outros tipos de resposta que emitam tokens de acesso na resposta de autorização.

Assim, o Fluxo Implícito foi oficialmente removido da especificação OAuth 2.1.

No Logto, o fluxo de código de autorização com PKCE é o único fluxo suportado para SPAs e aplicativos móveis. O fluxo de código de autorização fornece uma maneira mais segura de obter tokens de acesso ao trocar o código de autorização.

A concessão de Credenciais do Proprietário dos Recursos (ROPC) foi depreciada#

A concessão de credenciais de senha do proprietário dos recursos (ROPC) permite que o cliente troque o nome de usuário e senha do usuário por um token de acesso. Ela foi introduzida pela primeira vez na especificação OAuth 2.0 como uma forma de oferecer suporte a aplicações legadas, como autenticação básica HTTP ou aplicações nativas que não podiam utilizar os fluxos de tokens OAuth mais seguros.

O tipo de concessão ROPC foi marcado como não recomendado na especificação OAuth 2.0 devido aos seus riscos de segurança. As credenciais dos usuários são expostas à aplicação cliente, o que pode levar a possíveis brechas de segurança. A aplicação cliente pode armazenar as credenciais dos usuários, e se o cliente for comprometido, as credenciais dos usuários podem ser expostas a atacantes.

Posteriormente, na seção 2.4 das Melhores Práticas de Segurança de OAuth 2.0, a proibição do tipo de concessão ROPC foi ainda mais enfatizada como NÃO DEVE ser usada. Como resultado, o tipo de concessão ROPC foi removido da especificação OAuth 2.1.

Devido aos altos riscos de segurança associados ao tipo de concessão ROPC, o Logto nunca o suportou. Se você ainda estiver utilizando o fluxo direto de credenciais de usuários em suas aplicações legadas, recomendamos fortemente a migração para um método mais seguro, como o fluxo de código de autorização ou a concessão de credenciais do cliente. O Logto oferece vários SDKs e tutoriais para ajudar você a integrar esses fluxos seguros de OAuth em suas aplicações sem esforço.

Entendemos que os desenvolvedores podem querer projetar ou hospedar sua própria interface de login de usuários para oferecer a melhor experiência de produto. No Logto, oferecemos uma gama de opções de personalização de experiência de login (SIE), incluindo configurações de marca e CSS personalizado. Além disso, temos vários projetos em andamento, como traga sua própria interface de usuário e login direto, para oferecer mais flexibilidade aos desenvolvedores ao trazer sua própria interface de login, mantendo a segurança do fluxo de OAuth.

Conclusão#

OAuth 2.1 é a atualização mais recente do protocolo OAuth, voltada para enfrentar os desafios de segurança atuais enquanto abraça as necessidades modernas de aplicativos web e móveis. O grupo de trabalho OAuth está ativamente atualizando e refinando o OAuth 2.1 para garantir que ele atenda aos mais recentes padrões de segurança e melhores práticas. O mais recente rascunho, OAuth 2.1 11, foi lançado em maio de 2024, marcando progressos significativos em direção à sua finalização. Com a ampla adoção no horizonte, recomendamos fortemente que todos sigam as melhores práticas descritas no OAuth 2.1 para aumentar a segurança e melhorar a experiência do usuário.