A especificação do OAuth 2.1 foi planeada. Vamos explorar as principais diferenças entre o OAuth 2.0 e o OAuth 2.1 e como foram adotadas no Logto.
Desde que o OAuth 2.0 (RFC 6749) foi lançado em 2012, o mundo das aplicações web e móveis mudou bastante. As pessoas estão a migrar dos desktops para os dispositivos móveis, e as Aplicações de Página Única (Single Page Applications, SPAs) estão agora na moda. Também vimos uma explosão de novos frameworks e tecnologias web surgirem. Com todas essas mudanças, os desafios de segurança também se intensificaram. 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 exigências de segurança atuais, e é por isso que o OAuth 2.1 está a chegar.
No próximo OAuth 2.1, o Grupo de Trabalho do OAuth tem como objetivo consolidar todas as melhores práticas e recomendações de segurança num único documento. No Logto, mantemo-nos atualizados com os padrões e melhores práticas mais recentes do OAuth. Neste artigo, vamos explorar as principais diferenças entre o OAuth 2.0 e o OAuth 2.1 e como foram adotadas no Logto.
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 utilizem o fluxo de Authorization Code. PKCE é uma extensão de segurança que previne ataques de interceptação do código de autorização. É especialmente útil para aplicações móveis e 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 na sua capacidade de armazenar segredos com segurança:
Clientes confidenciais: Estes clientes podem armazenar segredos com segurança, como aplicações web renderizadas pelo servidor e servidores web. Todas as solicitações relacionadas à autorização são feitas do lado do servidor, e o risco de exposição do segredo do cliente é baixo.
Clientes públicos: Estes clientes não podem armazenar segredos com segurança, como aplicações móveis e SPAs. O segredo do cliente pode ser facilmente extraído do código do lado do cliente, sendo 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ó pode 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 baseado nesse verificador. O verificador de código é enviado para o servidor de autorização, e o desafio de código é usado para verificar o verificador de código durante a troca do 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 utilizem o fluxo de Authorization Code, independentemente do seu estatuto de confidencialidade — confidencial ou público. Esta alteração crucial garante proteção universal contra potenciais ataques de interceptação do código de autorização.
No Logto, o fluxo de validação PKCE é ativado automaticamente para clientes públicos e confidenciais.
Para SPAs e aplicações 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á imediatamente recusada pelo servidor de autorização do Logto.
Quanto aos clientes confidenciais (aplicações web tradicionais), para uma maior compatibilidade com legados, o Logto ainda permite a omissão do desafio de código na solicitação de autorização. No entanto, incentivamos fortemente que os clientes confidenciais adotem o PKCE, incorporando o desafio de código na solicitação de autorização, seguindo as práticas dos clientes públicos.
Um URI de Redirecionamento (Uniform Resource Identifier) é um endpoint ou URL específico para o qual o servidor de autorização redireciona o utilizador após o processo de autenticação e autorização.
Durante o fluxo OAuth, a aplicação cliente inclui um URI de Redirecionamento como parte da solicitação de autorização inicial. Uma vez que o utilizador completa o processo de autenticação, o servidor de autorização gera uma resposta que inclui um código de autorização e redireciona o utilizador de volta ao URI de Redirecionamento especificado. Qualquer desvio do URI de Redirecionamento original pode levar à fuga de código ou token.
A correspondência exata de strings de URIs de Redirecionamento foi introduzida pela primeira vez na seção 4.1 das Melhores Práticas de Segurança do OAuth 2.0. Esta prática assegura que o URI de Redirecionamento deve coincidir exatamente com o que foi registrado no servidor de autorização. Qualquer desvio do URI de Redirecionamento registado resultará numa resposta de erro.
Recebemos inúmeros pedidos da comunidade sobre a implementação de correspondência de wildcard para URIs de Redirecionamento. Embora a correspondência de wildcard possa oferecer conveniência para os programadores que administram vários 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 de uma validação de URI de Redirecionamento inadequada, consulta o nosso post do blog A brief OAuth security recap.
Em consonância com os rigorosos padrões de segurança do OAuth 2.1, o Logto utiliza a correspondência exata de strings para URIs de Redirecionamento. Esta decisão prioriza a segurança do fluxo OAuth. Em vez de utilizar a correspondência de wildcard, encorajamos os programadores a registarem todos os possíveis URIs de Redirecionamento no servidor de autorização do Logto. Isto assegura uma validação completa dos URIs de Redirecionamento e ajuda a mitigar potenciais vulnerabilidades de segurança.
O fluxo de concessão implícita no OAuth 2.0 foi projetado para SPAs, onde o token de acesso é devolvido diretamente no fragmento da URL após o utilizador se autenticar. Este método era conveniente porque evitava um passo adicional de troca de token, permitindo que o cliente recebesse o token diretamente.
No entanto, essa conveniência tem as suas desvantagens. 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, tornando mais fácil que ocorram 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, ela pode facilmente extrair o token de acesso do fragmento da URL e se fazer passar pelo utilizador.
Nas Melhores Práticas de Segurança do OAuth 2.0, está claramente afirmado que:
Os 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 do OAuth 2.1.
No Logto, o fluxo de código de autorização com PKCE é o único fluxo suportado para SPAs e Aplicações Móveis. O fluxo de código de autorização fornece uma maneira mais segura de obter tokens de acesso através da troca do código de autorização.
O tipo de concessão de credenciais do proprietário do recurso (ROPC) permite que o cliente troque o nome de utilizador e a senha do utilizador por um token de acesso. Foi introduzido pela primeira vez na especificação do OAuth 2.0 como uma forma de suportar aplicações legadas, como a autenticação básica HTTP ou aplicações nativas legadas que não podiam utilizar os fluxos tokenizados mais seguros do OAuth.
O tipo de concessão ROPC foi marcado como não recomendado na especificação do OAuth 2.0 devido aos seus riscos de segurança. As credenciais do utilizador são expostas à aplicação cliente, o que pode levar a potenciais falhas de segurança. A aplicação cliente pode armazenar as credenciais do utilizador, e se o cliente for comprometido, as credenciais do utilizador podem ser expostas a atacantes.
Posteriormente, na seção 2.4 das Melhores Práticas de Segurança do OAuth 2.0, a proibição do tipo de concessão ROPC foi ainda mais enfatizada e indicada como NÃO DEVE ser utilizada. Como resultado, o tipo de concessão ROPC foi removido da especificação do OAuth 2.1.
Devido aos altos riscos de segurança associados ao tipo de concessão ROPC, o Logto nunca o suportou. Se ainda estiveres a utilizar o fluxo direto de credenciais do utilizador nas tuas aplicações legadas, recomendamos fortemente migrar para um método mais seguro, como o fluxo de código de autorização ou a concessão de credenciais de cliente. O Logto oferece vários SDKs e tutoriais para te ajudar a integrar esses fluxos seguros do OAuth nas tuas aplicações de forma simples.
Compreendemos que os programadores podem querer projetar ou hospedar a sua própria interface de login de utilizador para proporcionar a melhor experiência de produto. No Logto, oferecemos uma variedade 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 o "traz o teu próprio UI" e "login direto", para fornecer mais flexibilidade aos programadores para trazerem a sua própria interface de login, mantendo a segurança do fluxo OAuth.
OAuth 2.1 é a atualização mais recente para o protocolo OAuth, orientada para lidar com os desafios de segurança de hoje enquanto abraça as necessidades modernas de aplicações web e móveis. O grupo de trabalho do OAuth está ativamente a atualizar e a refinar o OAuth 2.1 para garantir que ele atenda aos padrões de segurança e às melhores práticas mais recentes. O rascunho mais recente, OAuth 2.1 11, foi lançado em maio de 2024, marcando um progresso significativo em direção à sua finalização. Com a ampla adoção no horizonte, recomendamos fortemente que todos sigam as melhores práticas delineadas no OAuth 2.1 para melhorar a segurança e a experiência do utilizador.