How is oAuth more secure?

Question

Many services, for example IMAP mail by Google, has moved away from user id/password authentication to using oAuth.

How is oAuth more secure, besides it being a service provided by a large and well endowed company with more resources to monitor?

Answer 1

The technical benefits are:

• As the "initial authentication" part of OAuth is done through a website, it can more easily ask for other authentication factors than just a password. For example, it could ask for a TOTP one-time code or an U2F key. (It could also have reCAPTCHA if needed.)

  • Generally this also means that the password you're entering is only visible to the web browser – it is never actually seen by the mail app.

    Nowadays Google in particular is more aggressive about preventing the authentication page from being loaded inside "embedded" browsers which could be made to reveal the password to the host program. (Old GNOME versions used to do this semi-legitimately, as they needed to use certain Google APIs that at the time didn't yet support OAuth2.)

  • Using a website also allows the UI to be more consistent with actual web-based services and somewhat simpler to implement in apps than inventing a new custom multi-step authentication method.

    (Compare to SSH, which does have a "KeyboardInteractive" auth method that can display several prompts with custom text – works okay for basic password+OTP or keypair+OTP, but overall is rather clumsy when it comes to 2FA. Many corporations actually end up implementing systems that use short-lived SSH keypairs in a way extremely similar to OAuth2 tokens or Kerberos tickets – you authenticate through the corporate SSO website to get an SSH key for the day.)

• The token issued to your mail client only has access to specific services (scopes), in this case IMAP and SMTP – for example, it cannot be used to access your Drive files or your YouTube history.

  • Though this has potential for abuse on the service provider's side (e.g. Google requiring expensive "verification" for OAuth2 apps that have more than 100 users and want to access mail-related scopes).

  • Manually-generated "app passwords" could also be limited to specific services, but very few people would use that feature effectively – e.g. this is possible with GitHub access tokens but it takes too much mental effort to determine (often by trial and error) which scopes are needed for what app, so many tokens will be generated with every possible scope enabled...

There are also some "defense in depth" advantages for the service provider:

• The actual service never receives your actual password (nor even the refresh token – only the short-lived access token), so even if one service is compromised, it cannot collect credentials for accessing other services ("lateral movement"?).

  • This is very similar to the usage of Kerberos tickets in Active Directory, or SAML assertions in enterprise SSO systems.

    In all such systems, instead of all services requiring access to the user database (and all of them being valuable targets), you're left with only the KDC or IdP being in a privileged position.

Answer 2

I can see at least a few possible positives.

1. It reduces the chance of password re-use. The more places you type in a password the higher the chance of a critical leak and if you reuse passwords then other sites are at risk too.
2. It provides a central authority capable of quickly revoking access to a large number of sites in one go. Since sites are only given an "access token" by Google they can all be unique and revoked individually or all at once.
3. It hides the need for sites to handle password changes and to securely store passwords. If they never receive a password then they can't store it in plaintext, some sites did or probably still do.
   They should still handle the token securely, but it's a simpler process in the case of a breach. Inform OAuth provider of breach, and they revoke your token until you get a new one next time the user authenticates.

It does rely on your OAuth provider being secure, but resetting the password in one place is still far easier than doing it across 50 or 500 sites.