A resposta para sua pergunta pode estar no nível do código, do protocolo ou da arquitetura. Tentarei resumir aqui a maioria dos problemas no nível do protocolo, já que isso geralmente é crítico na análise de prós e contras. Lembre-se de que o OAuth2 é muito mais do que credenciais de senha do proprietário do recurso que, de acordo com a especificação, existem por "motivos herdados ou de migração", são consideradas "risco mais alto que outros tipos de concessão" e a especificação afirma explicitamente que os clientes e os servidores de autorização "DEVE minimizar o uso deste tipo de concessão e utilizar outros tipos de concessão sempre que possível".
Ainda existem muitas vantagens em usar o ROPC sobre a autenticação básica, mas antes de entrarmos nisso, vamos entender a diferença básica de protocolo entre o OAuth2 e a autenticação básica. Por favor, tenha paciência comigo enquanto explico isso e chegarei ao ROPC mais tarde.
Fluxos de autenticação do usuário
Existem quatro funções definidas na especificação do OAuth2. Com exemplos, eles são:
- Proprietário do recurso: o usuário que tem acesso a algum recurso, por exemplo, no seu caso, usuários diferentes podem ter diferentes níveis de acesso à API REST;
- O cliente: geralmente o aplicativo que o usuário está usando e precisa acessar o recurso para fornecer serviços ao usuário;
- Servidor de recursos: a API REST no seu caso; e
- Servidor de autorização: o servidor ao qual as credenciais do usuário são apresentadas e o que autenticará o usuário.
Quando um aplicativo cliente é executado, é concedido acesso aos recursos com base no usuário. Se um usuário tiver privilégios de administrador, os recursos e operações disponíveis para o usuário na API REST podem ser muito mais do que um usuário sem privilégios de administrador.
O OAuth2 também permite a possibilidade de usar um único servidor de autorização com vários clientes e para vários recursos. Como exemplo, um servidor de recursos pode aceitar a autenticação do usuário com o Facebook (que pode atuar como servidor de autorização nesse caso). Portanto, quando o usuário executa um aplicativo (ou seja, o cliente), ele envia o usuário para o Facebook. O usuário digita suas credenciais no Facebook e o cliente recebe um "token" que pode ser apresentado ao servidor de recursos. O servidor de recursos examina o token e o aceita depois de verificar se o Facebook realmente o emitiu e permite ao usuário acessar o recurso. Nesse caso, o cliente nunca vê as credenciais do usuário (ou seja, as credenciais do Facebook).
Mas digamos que você esteja gerenciando a identidade do usuário (e tenha um servidor de autorização) em vez do Facebook, que já concede tokens ao seu cliente. Agora, digamos que você também tenha um parceiro e deseje permitir que seu aplicativo (ou seja, cliente) acesse sua API REST. Com autenticação básica (ou mesmo ROPC), o usuário fornecerá credenciais para esse cliente, que a enviará ao servidor de autorização. O servidor de autorização fornecerá um token que pode ser usado pelo cliente para acessar os recursos. Infelizmente, isso significa que as credenciais do usuário agora também estão visíveis para esse cliente. No entanto, você não deseja que o aplicativo de um parceiro (que possa ser externo à sua organização) saiba a senha de um usuário. Esse é um problema de segurança agora. Para atingir esse objetivo,
Portanto, com o OAuth2, o ideal seria não usar o ROPC nesses casos, e sim usar um diferente, como o fluxo do código de autorização. Isso protege qualquer aplicativo de conhecer as credenciais do usuário que são apresentadas apenas ao servidor de autorização. Portanto, as credenciais de um usuário não são vazadas. Os mesmos problemas se aplicam à autenticação básica, mas na próxima seção, explicarei como o ROPC ainda é melhor porque as credenciais do usuário ainda não precisam ser armazenadas pelo cliente no ROPC para acesso persistente pelos clientes.
Observe que quando o usuário acessa o servidor de autorização, ele também pode solicitar ao usuário que confirme que deseja permitir que o cliente acesse os recursos em seu nome ou não. É por isso que é chamado servidor de autorização, porque o processo de autorização de um cliente para acessar recursos está envolvido no processo. Se o usuário não autorizar o cliente, ele não terá acesso aos recursos. Da mesma forma, se o próprio usuário não tiver acesso aos recursos, o servidor de autorização ainda poderá negar o acesso e não emitir um token.
Na autenticação básica, até o servidor de autorização e o servidor de recursos são combinados em uma única entidade. Portanto, o servidor de recursos deseja autorizar o usuário, solicitando as credenciais do cliente. O cliente fornece as credenciais usadas pelo servidor de recursos para autenticar o usuário. Isso significa que vários servidores de recursos exigirão essencialmente credenciais do usuário.
Emissão de tokens
Os clientes obtêm tokens do servidor de autorização, mantêm-nos por perto e os utilizam para acessar os recursos (mais detalhes sobre os próprios tokens abaixo). Os clientes nunca sabem a senha do usuário (em fluxos diferentes do ROPC) e não precisam armazená-la. No ROPC, mesmo que os clientes saibam a senha do usuário, eles ainda não precisam armazená-la porque usam esses tokens para acessar recursos. Por outro lado, na autenticação básica, se um cliente não deseja que o usuário forneça credenciais em todas as sessões, o cliente deve armazenar a senha do usuário para fornecê-la na próxima vez. Essa é uma grande desvantagem do uso da autenticação básica, a menos que o cliente seja apenas um aplicativo da Web; nesse caso, os cookies podem resolver algumas dessas preocupações. Com aplicativos nativos, isso geralmente não é uma opção.
Há outro aspecto do OAuth2 que está relacionado à forma como os tokens são emitidos e funcionam. Quando um usuário fornece credenciais ao servidor de autorização (mesmo no ROPC), o servidor de autorização pode fornecer um ou mais dos dois tipos de tokens: 1) token de acesso e 2) token de atualização.
Os tokens de acesso são enviados ao servidor de recursos, que concederá acesso aos recursos após a validação, e geralmente eles têm uma vida útil curta, por exemplo, 1 hora. Os tokens de atualização são enviados ao servidor de autorização pelo cliente para obter outro token de acesso quando ele expira e geralmente têm uma vida útil longa (por exemplo, alguns dias a meses ou até anos).
Quando o cliente fornece o token de acesso ao servidor de recursos, ele olha para o token e, após a validação, olha dentro do token para determinar se deve permitir acesso ou não. Desde que o token de acesso seja válido, o cliente pode continuar usando-o. Digamos que o usuário feche o aplicativo e o inicie no dia seguinte, e o token de acesso expirou. Agora, o cliente fará uma chamada para o servidor de autorização e apresentará o token de atualização, assumindo que ele não expirou. O servidor de autorização, uma vez que já emitiu o token, o verifica e pode determinar que o usuário não precisa fornecer as credenciais novamente e, portanto, fornece outro token de acesso ao cliente. O cliente agora tem acesso ao servidor de recursos novamente. É assim que geralmente os aplicativos clientes do Facebook e Twitter solicitam credenciais uma vez e, em seguida, não exigem que o usuário forneça credenciais novamente. Esses aplicativos nunca precisam conhecer as credenciais dos usuários e ainda podem acessar recursos toda vez que o usuário inicia o aplicativo.
Agora, o usuário pode acessar o servidor de autorização (por exemplo, no perfil de usuário do Facebook), alterar a senha sem afetar os aplicativos clientes. Todos continuarão funcionando corretamente. Se o usuário perder um dispositivo no qual ele já tinha um aplicativo com tokens de atualização, ele poderá solicitar ao servidor de autorização (por exemplo, o Facebook) para "desconectá-lo" dos aplicativos que o servidor de autorização (por exemplo, o Facebook) realizará por não respeitar nenhuma existente atualize os tokens e force o usuário a fornecer credenciais novamente quando tentar acessar recursos através desses aplicativos.
JWT é simplesmente o formato de token geralmente usado com OAuth2 e OpenID Connect. Os métodos de assinatura e validação do token também são padronizados com bibliotecas disponíveis para aqueles, em vez de todos os servidores de recursos que implementam outra solução. Portanto, a vantagem está na reutilização do código que foi examinado e continua a ser suportado.
Implicações de segurança
A autenticação básica será mais fraca quando qualquer um dos cenários acima estiver na imagem. Há também um extenso modelo de ameaça para o OAuth2 disponível para desenvolvedores que podem usar as sugestões contidas nele para evitar vulnerabilidades comuns em suas implementações. Se você seguir o modelo de ameaça, verá que muitas vulnerabilidades relacionadas à implementação (como redirecionador aberto e CSRF) também são cobertas. Não passei pela comparação daqueles contra autenticação básica nesta resposta.
A última grande vantagem do OAuth2 é que o protocolo é padronizado e vários servidores de autorização, clientes e servidores de recursos o honram. Várias bibliotecas estão disponíveis para desenvolvedores, que são mantidas para que problemas de segurança sejam encontrados nas implementações, as bibliotecas são atualizadas e permitem a interoperabilidade.
Conclusão
Se você estiver escrevendo um novo aplicativo, IMO, o caso ideal seria evitar a autenticação básica e o ROPC devido aos problemas inerentes a eles. No entanto, cada aplicativo tem necessidades, cronogramas, proficiência de desenvolvedor etc. diferentes, portanto, a decisão é caso a caso. Mas mesmo que você não tenha mais necessidade do que a autenticação básica, escolhendo-a, poderá se trancar em uma arquitetura que pode não ser fácil de estender (por exemplo, se você tiver vários servidores no futuro, não necessariamente precisará ter o usuário fornece credenciais para cada uma delas, apenas fornece ao servidor de autorização uma vez, o que pode distribuir tokens etc.)
Observe que eu não mencionei seu comentário sobre como as credenciais são enviadas por cabo, porque elas podem ser protegidas usando TLS ou um protocolo semelhante ou prova de posse, etc. Como alguém já sugeriu, a codificação da base 64 é 0 de segurança, por favor, não ser iludido por isso. As diferenças mencionadas acima geralmente são no nível arquitetural e, portanto, é aí que eu me concentro, porque a arquitetura é a mais difícil de mudar depois de implementada.
O Azure Active Directory B2C Basic , um serviço no qual trabalho e foi lançado recentemente para visualização pública, permite que aplicativos de terceiros usem o AAD como servidor de autorização com interoperabilidade com IDPs sociais (como Facebook, Google etc.). Ele também permite que os usuários criem suas próprias contas em vez de usar IDPs sociais e esses podem ser usados posteriormente para fins de autenticação. Existem alguns outros serviços como esse (por exemplo, outro que eu conheço é o auth0), que pode ser usado pelos desenvolvedores para terceirizar completamente a autenticação e o gerenciamento de usuários para seus aplicativos e recursos. As mesmas características de protocolo mencionadas acima são usadas pelos desenvolvedores para desacoplar o servidor de autorização (AAD), um recurso (por exemplo, suas APIs REST), o cliente (por exemplo, seus aplicativos móveis) e usuários. Espero que esta explicação ajude um pouco.