OAuth 2.0 - NUNCA utilize Resource Owner Password Credentials
OAuth 2.0IdentityServer4Microsservicos
by Bruno Brito on 10 de Agosto de 2019 Read in 6 min
Se o globo.com solicitasse tuas credenciais do Google, você forneceria? Isso te soa estranho? Então, é exatamente o que o Resource Owner Password Credential faz.
Os desenvolvedores costumam chegar no OAuth2 percorrendo o caminho de Microsserviços. Os times .NET encontram no IdentityServer4 seu provedor de Identidade e Autorização. E então essas equipes passam a ter dúdivas sobre o OAuth2 & OIDC.
Se você já buscou sobre esse tema. Assistiu palestras do Elemar Jr ou Milton Câmara, já deve ter se esbarrado que o primeiro passo na adoção de Microsserviços é ter um Authorization Server.
Você tem um Monolito, está trabalhando numa empresa grande, com diversos sistemas e API's. Certamente Identidade já é um problema resolvido.
É nesse ambiente que o Resource Owner Password Credential (ROPC), aparece como uma boa saída para adotar o IdentityServer4.
Aparentemente isso acontece pois em ambientes corporativos. Implantar um sistema de "usuário e senha", parece ser um tema resolvido e superado.
Os exemplos mais comuns de IdentityServer, quase que em sua totalidade montam um servidor básico de Autenticação, para então construir simples API's.
E nesse mar de dúvidas, questionamentos e sopa de letrinhas: OAuth2, IdentityServer, Bearer, JWT, Cookies, OpenId Connect, Microsserviços. Uma pergunta cabivel é: Como encaixar o cenário atual nesse novo contexto?
Autenticação é uma feature que já existe, logo "não há a necessidade de reconstruir um fluxo de login de usuários".
E dai surge a ideia: Com o ROPC, o sistema atual chama o IdentityServer4, passando as credenciais do usuário e... Pronto! Apenas umas linhas de código, usuário validado, token na mão e problema resolvido. Não precisa desenvolver novamente um fluxo de login de usuários.
Utilizar ROPC é uma má ideia, tanto que o OAuth Working Group declarou ele como deprecated.
A RFC diz que pode ser utilizado o ROPC em casos em que há uma relação de confiança entre o Client e o Server.
"Se já tenho alguns frontends que fazem login, tem a tela pronta, por que fazer uma nova? Basta usar o ROPC".
Dessa forma há ganhos imediatos. O beneficio dos tokens JWT. Com refresh token, claims e tudo aquilo que mais atrai no OAuth.
Se tem tudo isso de bom, por que evitar?
Embora a resposta mais correta sobre a utilização do ROPC seja Depende. No geral não é uma boa idéia.
ROPC na prática é impersonate. O que pode ser comparado com um phishing attack. Ao utiliza-lo não há como saber se Resource Owner (Usuário) é quem, de fato, está fazendo essa solicitação.
Single Factor auth
Resource Owner Password Credentials NÃO É AUTENTICAÇÃO. Se você implementou um 2FA, 3FA. Utilizar ROPC não vai solicitar os demais fatores de autenticação. Como SMS, E-mail ou OTP.
Má pratica
O artigo começa citando o exemplo da Globo. Quando um Client utiliza ROPC para autenticar seu usuário. Comparativamente é como se a Globo.com solicitasse seu usuário e senha do Google para poder acessar o conteúdo do portal. Ao invés de te redirecionar para o site do Google.
É perdoável esse exemplo se tanto o Client como o Auth Server é interno da empresa. Caso contrário, se o Client ou Auth Server forem externos. A cada login com sucesso no Client, Deus mata um panda.
Inclusive a próprio RFC do OAuth2 faz um alerta sobre isso.
Todos acessos do usuário
Esse é um ponto alarmante. Apesar do OAuth2 limitar os Scopes que o Client pode acessar. Por exemplo, o Client não pode acessar a API de Relatórios.
Porém um desenvolvedor malicioso, com o usuário e senha do usuário em mãos. Pode burlar a autenticação simulando o login em outro Client, que por sua vez, gera um novo token. E em posse desse novo token, consegue acessar a API de relatório.
Não é Single Sign On
Uma vez que o Client não redireciona para o Auth Server, perde o conceito de Single Sign On e Single Sign Out.
Não é possivel se logar através das redes sociais, ou de qualquer provedor externo. Pois o ROPC exige usuário e senha.
Você se importa com segurança? Não utilize ROPC. Pode ser que o Client não tenha proteções para a Autentição, como um ataque de brute force.
O OAuth Working Group declarou o ROPC como deprecated.
The resource owner password credentials grant MUST NOT be used. This
grant type insecurely exposes the credentials of the resource owner
to the client. Even if the client is benign, this results in an
increased attack surface (credentials can leak in more places than
just the AS) and users are trained to enter their credentials in
places other than the AS.
Client externo
Se o client for externo. Por exemplo, em parceiro que esteja construindo uma ferramenta utilizando suas api's. Jamais dê ROPC a ele. Pois vai comproter as credenciais de teus usuários.
Quer mais motivo para não utilizar ROPC? Então, novamente a RFC diz:
Evite cair nas armadilhas
Essas duas situações são bem comum. Levando os times a tomarem a decisão de utilizar ROPC.
Sem tempo para desenvolver o Frontend? Não se preocupe, há projetos open source que resolvem isso.
QuickstartUI
E também não necessário ficar preso ao .NET. Há alternativas de SSO como OKTA, Auth0 e KeyCloak.
Só tenho um frontends
Você está caminhando para um mundo de Microsserviços, com centenas de api's. Muito em breve, haverá mais de um client frontend. Se você se pegar pensando nesse argumento, pare! Se só há um ou dois frontends e esse cenário nunca vai mudar, será que precisa mesmo de um server OAuth2?
Além disso, você vai duplicar o código em todos os clients para autenticar?
Por que utilizar o Auth Server
Existem boas razões para criar um Auth Server ou adequar o atual. E utilizar um flow apropriado. Evitando utilizar o ROPC.
Single Sign On - Evita a duplicação de código
Adequar a empresa para aderir protocolos consagradas de Autenticação e Autorização. OAuth2 & OpenId Connect.
Compátivel com modelos role-based
É um Microsserviço - Autenticação como serviço.
Nunca vi um cenário que não houvesse um flow alternativo ao ROPC. E tenho visto muitas equipes optarem por ele, principalmente para aproveitar fluxo de login legado. Espero que esse artigo te ajude a tomar decisões melhores.