Porque deve descontinuar o tipo de concessão Resource Owner Password Credentials (ROPC)

Introdução#

O tipo de concessão Resource Owner Password Credentials (ROPC), também conhecido como tipo de concessão de senha, é um fluxo OAuth 2.0 que permite a uma aplicação trocar o nome de utilizador e a senha de um utilizador por um token de acesso. Foi introduzido pela primeira vez na especificação OAuth 2.0 como uma forma de dar suporte a aplicações legadas, como autenticação básica HTTP ou aplicações nativas legadas que não podiam usar os fluxos de token OAuth mais seguros.

No entanto, o tipo de concessão ROPC apresenta vários riscos de segurança e foi marcado como NÃO DEVE ser usado nas melhores práticas de segurança OAuth 2.0.

Recentemente, recebemos várias perguntas dos nossos clientes a solicitar orientações ou suporte para implementar o tipo de concessão ROPC. Neste post, explicaremos por que deve evitar o uso do tipo de concessão ROPC, especialmente para as suas novas aplicações.

Tipo de concessão ROPC vs. fluxo de código de autorização#

Como funciona o tipo de concessão ROPC#

O tipo de concessão ROPC é um fluxo simples que troca o nome de utilizador e a senha do utilizador por um token de acesso. A aplicação cliente recolhe diretamente as credenciais do utilizador e envia-as diretamente para o servidor de autorização. O servidor de autorização valida as credenciais e emite um token de acesso para o cliente.

Como funciona o fluxo de código de autorização#

Em contraste, o fluxo de código de autorização é o fluxo OAuth 2.0 recomendado para aplicações web. Envolve várias etapas e redirecionamentos entre a aplicação cliente, o servidor de autorização e o navegador do utilizador. O fluxo de código de autorização é mais seguro porque não expõe as credenciais do utilizador para a aplicação cliente.

A principal diferença entre o tipo de concessão ROPC e o fluxo de código de autorização é que o ROPC expõe as credenciais do utilizador para a aplicação cliente, enquanto o fluxo de código de autorização não. As credenciais do utilizador devem ser mantidas confidenciais dentro do servidor de autorização. Sempre que uma aplicação cliente solicitar um recurso em nome do utilizador, deve redirecionar o utilizador para o servidor de autorização para autenticar e autorizar a aplicação cliente. Isso mantém a quantidade mínima de dados de autorização no lado da aplicação cliente.

Riscos de segurança do tipo de concessão ROPC#

1. Exposição de credenciais do utilizador#

Como mencionamos anteriormente, o tipo de concessão ROPC expõe as credenciais do utilizador para a aplicação cliente. Isso é um risco de segurança significativo porque a aplicação cliente pode armazenar ou registar as credenciais do utilizador e obter reautorização sem o conhecimento do utilizador.

Especialmente para uma aplicação pública como uma aplicação móvel ou uma aplicação de página única, a aplicação cliente pode ser facilmente injetada ou retroengenheirada para extrair as credenciais do utilizador. Nem uma aplicação móvel nem uma aplicação de página única que executa no navegador do utilizador podem manter segredos de forma confidencial. Assim, não podem autenticar o utilizador sem expor as credenciais do utilizador.

Mesmo que o proprietário do recurso tenha uma relação de confiança com a aplicação cliente, a aplicação cliente desempenha o papel de intermediário em todo o processo de autenticação, podendo ser comprometida por um outro ator malicioso. O ator malicioso pode roubar as credenciais do utilizador e se passar pelo utilizador para acessar os seus recursos.

Existem várias maneiras de roubar as credenciais do utilizador, dependendo da postura de segurança da aplicação cliente, como keyloggers, ataques de phishing ou malwares. Sem mencionar que as credenciais do utilizador são transmitidas pela rede em todas as solicitações de autorização. Isso aumenta ainda mais o risco de intercepção de credenciais.

Imagine se você tiver várias aplicações que usam o tipo de concessão ROPC, o potencial risco de exposição das credenciais é multiplicado.

2. O ROPC não suporta consentimento do utilizador#

O tipo de concessão ROPC não suporta o consentimento do utilizador. Quando a aplicação cliente recolhe as credenciais do utilizador diretamente, o utilizador não tem a oportunidade de revisar e aprovar o acesso da aplicação cliente aos seus recursos. Isso é uma violação da privacidade e confiança do utilizador.

Os utilizadores devem ter o direito de decidir quais aplicações clientes podem acessar os seus recursos e por quanto tempo. Especialmente para aplicações de terceiros, um mecanismo de consentimento do utilizador é essencial para proteger os dados do proprietário do recurso e é essencial para cumprir com regulamentos de proteção de dados como o RGPD.

3. O ROPC não suporta autenticação multifatorial#

Autenticação multifatorial (MFA) é uma implementação de segurança que exige que o utilizador forneça dois ou mais fatores de verificação para acessar os seus recursos. Adiciona uma camada extra de segurança ao processo de autenticação. O tipo de concessão ROPC não suporta MFA. Em vez disso, restringe o processo de autenticação a um único fator, e a solicitação de token é baseada apenas nas credenciais do utilizador. É impossível implementar mecanismos de autenticação baseados em desafio, como SMS OTP, email OTP ou WebAuthn com o tipo de concessão ROPC.

O ROPC não é compatível com aplicações modernas#

O tipo de concessão ROPC foi projetado para dar suporte a aplicações legadas que não podiam suportar sistemas modernos de IAM, Single Sign-On (SSO) ou identidades federadas.

1. O ROPC não é compatível com SSO#

Single Sign-On (SSO) é uma arquitetura de autenticação moderna que permite que os utilizadores façam login uma vez e acessem várias aplicações sem esforço.

Um IdP centralizado desempenha um papel crucial na arquitetura SSO. Ele gere a sessão de autenticação do utilizador e emite tokens para as aplicações clientes. As aplicações clientes não precisam recolher diretamente as credenciais do utilizador, e as credenciais do utilizador são mantidas confidenciais dentro do IdP.

O tipo de concessão ROPC não suporta SSO. Exige que a aplicação cliente recolha as credenciais do utilizador diretamente, o que quebra a arquitetura SSO. Não é compatível com sistemas SSO modernos como OpenID Connect (OIDC) ou SAML.

2. O ROPC não é compatível com identidades federadas#

Semelhante à arquitetura SSO, as identidades federadas permitem que os utilizadores usem a sua identidade existente para acessar várias aplicações de terceiros. Um utilizador pode vincular várias contas sociais, como Google, Facebook ou Twitter, a um IdP centralizado e usar essas contas sociais para autenticar com as aplicações clientes. Todas as identidades federadas são geridas pelo IdP, e as aplicações clientes não estão cientes dos detalhes de autenticação do utilizador nos bastidores.

O tipo de concessão ROPC, em vez disso, requer que a aplicação cliente recolha diretamente as credenciais do utilizador. Limita a capacidade da aplicação cliente de suportar identidades federadas e expõe os dados de identidade do utilizador para a aplicação cliente.

Conclusão#

O tipo de concessão Resource Owner Password Credentials (ROPC) é um fluxo legado do OAuth 2.0 que apresenta riscos de segurança significativos e deve ser descontinuado. Ele expõe as credenciais do utilizador para a aplicação cliente, não suporta mecanismos de segurança modernos como MFA ou SSO. Recomendamos fortemente que evite usar o tipo de concessão ROPC nas suas aplicações. Se tem sistemas de autenticação legados que dependem do tipo de concessão ROPC, considere migrar para fluxos OAuth 2.0 mais seguros, como o fluxo de código de autorização ou o fluxo de credenciais do cliente.

Contacte-nos se precisar de ajuda para integrar um serviço seguro de autenticação e autorização de utilizadores nas suas aplicações, ou para migrar de um sistema de autenticação baseado em senha legado para um fluxo OAuth 2.0 mais seguro. Estamos aqui para ajudar você a construir aplicações seguras e modernas.