Se o globo.com pedisse suas credenciais do Google, você entregaria sorrindo? Parece estranho, né? Mas é isso que o modo Resource Owner Password Credential (ROPC) faz com sua vida digital. Vamos lá!
Os desenvolvedores, sempre explorando o mundo do OAuth2 quando se perdem nos Microsserviços. Lá estão os times .NET, encantados com o IdentityServer4, achando que resolveram identidade e autorização rapidinho. Até que começam as dúvidas sobre o OAuth2 & OIDC, surgindo como pipoca no micro-ondas.
Microsserviços
O mundo dos Microsserviços! Se você já pensou em entrar nesse universo, já deve ter visto apresentações legais de Elemar Jr ou Milton Câmara. A primeira lição: tenha um Authorization Server antes até de tomar seu café.
A jornada
Imagine: você está lidando com um Monolito! Isso mesmo, um daqueles sistemas gigantes em uma grande empresa que adora seus sistemas e APIs. Identidade já deveria ser um problema resolvido... ou talvez não.
Entra o famoso Resource Owner Password Credential (ROPC), a solução rápida para integrar o IdentityServer4. Por que criar um login do zero quando você pode só remendar algo?
Por que?
No mundo corporativo, criar “usuário e senha” é coisa de um passado distante. Nos exemplos do IdentityServer, você encontra um servidor básico que te deixa achar que tudo é fácil.
Nesse conjunto de siglas mágicas da tecnologia, surgem as perguntas: Como seu sistema atual se encaixa nesse novo cenário?
"Autenticação já existe!", dizem por aí. Vamos usar o ROPC, mandar as credenciais para o IdentityServer4 e, voilá! Um token na mão e problema resolvido. Criar outro fluxo de login? Que piada.
Usar ROPC parece tão genial que o OAuth Working Group já o chamou de uma relíquia de tempos mais simples.
Resource Owner Password Credentials
A famosa RFC diz que só use o ROPC se o client e o server forem bem amigos.
O ROPC é adequado quando o dono dos recursos confia no cliente, como em um sistema operacional de dispositivo ou uma aplicação de alto privilégio. O servidor de autenticação deve ter cuidado ao habilitar este tipo e só usá-lo quando outros fluxos não forem viáveis.
RFC 6749 The OAuth 2.0 Authorization Framework - Section 4.3
Você se pergunta: "Por que criar um novo login se já tenho vários prontos? É só usar o ROPC!"
Olha só, benefícios na hora! Tokens JWT mágicos, com refresh token e tudo mais que faz o OAuth parecer a solução do futuro.
Com tudo isso, por que alguém evitaria?
Por que evitar?
Apesar de o ROPC parecer lindo, ele traz problemas.
Impersonate
Pronto, você abriu as portas para os invasores. O ROPC é o paraíso deles. Está competindo com phishing para ver quem faz mais vítimas.
Single Factor auth
E não se engane! O ROPC não é AUTENTICAÇÃO. Ama 2FA ou 3FA? Infelizmente, o ROPC não exige nada disso.
Má prática
Lembra do exemplo da Globo? Se o Client usa ROPC, é como se Globo.com te pedisse suas credenciais do Google em vez de te mandar pro site do Google.
A RFC do OAuth2 já avisa que isso é uma cagada.
Este tipo de concessão tem um risco maior porque mantém o anti-padrão de senha que este protocolo tenta evitar.
RFC 6749 The OAuth 2.0 Authorization Framework - Section 10.7
Todos acessos do usuário
Cuidado! Mesmo com promessas de limitar Scopes, um desenvolvedor mal-intencionado com suas credenciais pode acessar APIs proibidas.
Não é Single Sign On
Sem redirecionamento e afins, você perde o conceito de Single Sign On e Single Sign Out.
Federation Gateway
Login via redes sociais? Esqueça, ROPC só ama “usuário e senha”. Provedores externos? Sonhe.
Segurança
Se você se preocupa com segurança, evite o ROPC. É um convite aberto para ataques de força bruta.
Deprecated
O grupo OAuth Working cansou de ver o desastre do ROPC e o declarou obsoleto.
ROPC não deve ser usado. Ele expõe as credenciais do dono dos recursos de forma insegura para o cliente.
OAuth 2.0 Security Best Current Practice
Client externo
Se o client é externo, guarde o ROPC na gaveta, junto com aquela meia sem par.
Mais motivos?
Quer mais razões para evitar ROPC? A RFC continua explicando:
Porque o dono dos recursos não controla o processo de autorização, o cliente pode obter tokens com escopo maior do que o desejado.
RFC 6749 The OAuth 2.0 Authorization Framework - Section 10.7
Evite cair nas armadilhas
Aqui estão as ciladas que levam times a abraçar o ROPC.
Frontend
Sem tempo para construir o Frontend? Não se preocupe! Projetos open source são a solução.
Não fique só no .NET! Outras opções existem, como OKTA, Auth0, e KeyCloak.
Só tenho um frontend
Está sonhando com mundos de Microsserviços, com muitas APIs? Pergunte-se: você realmente precisa de um server OAuth2? Garanta que todos os requisitos são atendidos antes de entrar nessa.
Por que usar o Auth Server
Sim, há razões para construir ou ajustar um Auth Server, usando fluxos adequados, sem o ROPC.
- Single Sign On – Evitando repetição.
- Protocolos consagrados: OAuth2 & OpenId Connect.
- Segurança melhorada.
- Compatível com modelos baseados em roles.
- Serviço de autenticação – em um cenário de Microsserviços, é comum ter a autenticidade como serviço.
Conclusão
Apesar de o ROPC ser um atalho para desenvolvedores apressados, uma abordagem correta e segura é sempre melhor. Este texto, com um toque de humor, busca revelar algumas verdades.
Dúvidas? Críticas? Sugestões? Deixe seu comentário e vamos conversar!
Fale conosco