Como o oAuth é mais seguro?

Eu posso ver pelo menos alguns pontos positivos possíveis.

1. Reduz a chance de reutilização de senha. Quanto mais lugares você digitar uma senha, maior será a chance de um vazamento crítico e, se você reutilizar senhas, outros sites também estarão em risco.
2. Ele fornece uma autoridade central capaz de revogar rapidamente o acesso a um grande número de sites de uma só vez. Como os sites recebem apenas um "token de acesso" do Google, todos podem ser únicos e revogados individualmente ou todos de uma vez.
3. Ele oculta a necessidade de os sites lidarem com alterações de senha e armazenarem senhas com segurança. Se eles nunca receberem uma senha, não poderão armazená-la em texto simples, alguns sites receberam ou provavelmente ainda recebem.
   Eles ainda devem lidar com o token com segurança, mas é um processo mais simples no caso de uma violação. Informe o provedor OAuth da violação e ele revogará seu token até que você obtenha um novo na próxima vez que o usuário se autenticar.

Ele depende da segurança do seu provedor OAuth, mas redefinir a senha em um só lugar ainda é muito mais fácil do que fazê-lo em 50 ou 500 sites.

Os benefícios técnicos são:

• Como a parte de "autenticação inicial" do OAuth é feita por meio de um site, ele pode solicitar mais facilmente outros fatores de autenticação do que apenas uma senha. Por exemplo, ele pode solicitar um código de uso único TOTP ou uma chave U2F. (Também pode ter reCAPTCHA, se necessário.)

  • Geralmente, isso também significa que a senha que você está digitando é visível apenas para o navegador da Web – ela nunca é vista pelo aplicativo de e-mail.

    Atualmente, o Google, em particular, é mais agressivo em impedir que a página de autenticação seja carregada em navegadores "incorporados", que podem revelar a senha para o programa host. (Versões antigas do GNOME costumavam fazer isso de forma semilegítima, pois precisavam usar certas APIs do Google que na época ainda não suportavam OAuth2.)

  • O uso de um site também permite que a interface do usuário seja mais consistente com os serviços reais baseados na Web e um pouco mais simples de implementar em aplicativos do que inventar um novo método de autenticação personalizado em várias etapas.

    (Compare com o SSH, que tem um método de autenticação "KeyboardInteractive" que pode exibir vários prompts com texto personalizado - funciona bem para senha básica + OTP ou par de chaves + OTP, mas no geral é bastante desajeitado quando se trata de 2FA. Muitas empresas realmente terminam implementando sistemas que usam pares de chaves SSH de curta duração de uma maneira extremamente semelhante a tokens OAuth2 ou tíquetes Kerberos – você autentica por meio do site de SSO corporativo para obter uma chave SSH para o dia.)

• O token emitido para seu cliente de e-mail só tem acesso a serviços específicos (escopos), neste caso IMAP e SMTP – por exemplo, ele não pode ser usado para acessar seus arquivos do Drive ou seu histórico do YouTube.

  • Embora isso tenha potencial para abuso do lado do provedor de serviços (por exemplo, o Google exige "verificação" cara para aplicativos OAuth2 que têm mais de 100 usuários e desejam acessar escopos relacionados a e-mail).

  • As "senhas de aplicativos" geradas manualmente também podem ser limitadas a serviços específicos, mas muito poucas pessoas usariam esse recurso de forma eficaz - por exemplo, isso é possível com tokens de acesso do GitHub, mas é preciso muito esforço mental para determinar (geralmente por tentativa e erro) quais escopos são necessários para qual aplicativo, então muitos tokens serão gerados com todos os escopos possíveis habilitados...

Existem também algumas vantagens de "defesa em profundidade" para o provedor de serviços:

• O serviço real nunca recebe sua senha real (nem mesmo o token de atualização – apenas o token de acesso de curta duração), portanto, mesmo que um serviço seja comprometido, ele não poderá coletar credenciais para acessar outros serviços ("movimento lateral"?).

  • Isso é muito semelhante ao uso de tíquetes Kerberos no Active Directory ou declarações SAML em sistemas SSO corporativos.

    Em todos esses sistemas, em vez de todos os serviços exigirem acesso ao banco de dados do usuário (e todos eles serem alvos valiosos), você fica apenas com o KDC ou o IdP em uma posição privilegiada.