Por que você deve descontinuar o tipo de concessão de Credenciais de Senha do Proprietário do Recurso (ROPC)

Introdução#

O tipo de concessão de Credenciais de Senha do Proprietário do Recurso (ROPC), também conhecido como tipo de concessão de senha, é um fluxo do OAuth 2.0 que permite que uma aplicação troque o nome de usuário e a senha de um usuário por um token de acesso. Ele foi introduzido pela primeira vez na especificação do OAuth 2.0 como uma forma de dar suporte a aplicações legadas, como autenticação básica HTTP ou aplicativos nativos legados que não podiam usar os fluxos de token do 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 do OAuth 2.0.

Recentemente, recebemos várias perguntas de nossos clientes solicitando orientação ou suporte para implementar o tipo de concessão ROPC. Neste post, explicaremos por que você deve evitar usar o tipo de concessão ROPC, especialmente para 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 usuário e a senha do usuário por um token de acesso. A aplicação cliente coleta as credenciais do usuário diretamente e as envia diretamente para o servidor de autorização. O servidor de autorização entã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. Ele envolve várias etapas e redirecionamentos entre a aplicação cliente, o servidor de autorização e o navegador do usuário. O fluxo de código de autorização é mais seguro porque não expõe as credenciais do usuário para a aplicação cliente.

As principais diferenças entre o tipo de concessão ROPC e o fluxo de código de autorização são que o ROPC expõe as credenciais do usuário para a aplicação cliente, enquanto o fluxo de código de autorização não. As credenciais do usuário devem ser mantidas confidenciais dentro do servidor de autorização. Sempre que uma aplicação cliente solicitar um recurso em nome do usuário, ela deve redirecionar o usuário para o servidor de autorização para autenticar e autorizar a aplicação cliente. Isso mantém uma 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 das credenciais do usuário#

Como mencionado anteriormente, o tipo de concessão ROPC expõe as credenciais do usuário para a aplicação cliente. Este é um risco de segurança significativo porque a aplicação cliente pode armazenar ou registrar as credenciais do usuário e se reautorizar sem o conhecimento do usuário.

Especialmente para uma aplicação cliente pública, como um aplicativo móvel ou uma aplicação de página única, a aplicação cliente pode ser facilmente injetada ou feita engenharia reversa para extrair as credenciais do usuário. Nem um aplicativo móvel nem uma aplicação de página única que roda no navegador do usuário podem manter segredos de forma confidencial. Assim, eles não podem autenticar o usuário sem expor as credenciais do usuário.

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

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

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

2. O ROPC não suporta consentimento do usuário#

O tipo de concessão ROPC não suporta consentimento do usuário. Quando a aplicação cliente coleta as credenciais do usuário diretamente, o usuário 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 usuário.

Os usuários devem ter o direito de decidir qual aplicação cliente pode acessar seus recursos e por quanto tempo. Especialmente para aplicações de terceiros, um mecanismo de consentimento do usuário é essencial para proteger os dados do proprietário do recurso e é fundamental para cumprir com regulamentos de proteção de dados como GDPR.

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

A autenticação multifator (MFA) é uma implementação de segurança que requer que o usuário forneça dois ou mais fatores de verificação para acessar seus recursos. Ela 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, ele restringe o processo de autenticação a um único fator, e a solicitação de token é baseada apenas nas credenciais do usuário. É impossível implementar mecanismos de autenticação baseados em desafios, como SMS OTP, e-mail 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 podem suportar sistemas modernos de IAM (Identity and Access Management), como 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 usuários façam login uma vez e acessem várias aplicações sem esforço.

Um Provedor de Identidade (IdP) centralizado desempenha um papel crucial na arquitetura SSO. Ele gerencia a sessão de autenticação do usuário e emite tokens para as aplicações clientes. As aplicações clientes não precisam coletar as credenciais do usuário diretamente, e as credenciais do usuário são mantidas confidenciais dentro do IdP.

O tipo de concessão ROPC não suporta SSO. Ele requer que a aplicação cliente colete as credenciais do usuário diretamente, o que quebra a arquitetura SSO. Ele não é compatível com sistemas modernos de SSO como OpenID Connect (OIDC) ou SAML.

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

Semelhante à arquitetura SSO, identidades federadas permitem que os usuários usem sua identidade existente para acessar várias aplicações de terceiros. Um usuário pode vincular várias contas sociais como Google, Facebook ou Twitter a um IdP centralizado e usar essas contas sociais para se autenticar com as aplicações clientes. Todas as identidades federadas são gerenciadas pelo IdP, e as aplicações clientes não têm conhecimento dos detalhes da autenticação do usuário.

O tipo de concessão ROPC, por outro lado, requer que a aplicação cliente colete as credenciais do usuário diretamente. Isso limita a capacidade da aplicação cliente de suportar identidades federadas e expõe os dados de identidade do usuário para a aplicação cliente.

Conclusão#

O tipo de concessão de Credenciais de Senha do Proprietário do Recurso (ROPC) é um fluxo legado do OAuth 2.0 que apresenta riscos significativos de segurança e deve ser descontinuado. Ele expõe as credenciais do usuário para a aplicação cliente e não suporta mecanismos de segurança modernos, como MFA ou SSO. Recomendamos fortemente evitar o uso do tipo de concessão ROPC em suas aplicações. Se você possui 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.

Entre em contato conosco se precisar de ajuda para integrar um serviço seguro de autenticação e autorização de usuários em suas aplicações, ou migrar de um sistema de autenticação baseado em senha legado para um fluxo OAuth 2.0 mais seguro. Estamos aqui para ajudá-lo a construir aplicações seguras e modernas.