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.
Microsserviços
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.
A jornada
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.
Por que?
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.
Resource Owner Password Credentials
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.
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
"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?
Por que evitar?
Embora a resposta mais correta sobre a utilização do ROPC seja Depende. No geral não é uma boa idéia.
Impersonate
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.
This grant type carries a higher risk than other grant types because it maintains the password anti-pattern this protocol seeks to avoid. The client could abuse the password, or the password could unintentionally be disclosed to an attacker (e.g., via log files or other records kept by the client).
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.
Federation Gateway
Não é possivel se logar através das redes sociais, ou de qualquer provedor externo. Pois o ROPC exige usuário e senha.
Segurança
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.
Deprecated
O OAuth Working Group declarou o ROPC como deprecated.
Resource Owner Password Credentials GrantThe 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.
Mais motivos?
Quer mais motivo para não utilizar ROPC? Então, novamente a RFC diz:
Additionally, because the resource owner does not have control over the authorization process (the resource owner's involvement ends when it hands over its credentials to the client), the client can obtain access tokens with a broader scope than desired by the resource owner. The authorization server should consider the scope and lifetime of access tokens issued via this grant type.The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible.
Evite cair nas armadilhas
Essas duas situações são bem comum. Levando os times a tomarem a decisão de utilizar ROPC.
Frontend
Sem tempo para desenvolver o Frontend? Não se preocupe, há projetos open source que resolvem isso.
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.
- Melhorar a segurança.
- Compátivel com modelos role-based
- É um Microsserviço - Autenticação como serviço.
Conclusã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.
Tem duvidas? Criticas ? Sugestões? deixe seu comentário e vamos batendo um papo!
Comments