Как oAuth более безопасен?

Я вижу по крайней мере несколько возможных положительных моментов.

1. Это снижает вероятность повторного использования пароля. Чем больше мест вы вводите пароль, тем выше вероятность критической утечки, и если вы повторно используете пароли, то другие сайты также подвергаются риску.
2. Он обеспечивает центральный орган, способный быстро отозвать доступ к большому количеству сайтов за один раз. Поскольку Google предоставляет сайтам только «токен доступа», все они могут быть уникальными и отзываться по отдельности или все сразу.
3. Это скрывает необходимость для сайтов обрабатывать изменения паролей и безопасно хранить пароли. Если они никогда не получают пароль, они не могут хранить его в открытом виде, как это делали некоторые сайты или, вероятно, до сих пор делают.
   Им по-прежнему следует безопасно обращаться с токеном, но в случае взлома это более простой процесс. Сообщите провайдеру OAuth о нарушении, и он отзовет ваш токен до тех пор, пока вы не получите новый при следующей аутентификации пользователя.

Он действительно зависит от безопасности вашего провайдера OAuth, но сбросить пароль в одном месте все равно намного проще, чем делать это на 50 или 500 сайтах.

Технические преимущества заключаются в следующем:

• Поскольку часть «начальной аутентификации» OAuth выполняется через веб-сайт, ему легче запросить другие факторы аутентификации, чем просто пароль. Например, он может запросить одноразовый код TOTP или ключ U2F. (При необходимости он также может иметь reCAPTCHA.)

  • Как правило, это также означает, что вводимый вами пароль виден только веб-браузеру — почтовое приложение никогда его не видит.

    В настоящее время Google, в частности, более агрессивно относится к предотвращению загрузки страницы аутентификации во «встроенных» браузерах, которые могут раскрыть пароль хост-программе. (Старые версии GNOME делали это полулегально, поскольку им нужно было использовать определенные API Google, которые в то время еще не поддерживали OAuth2.)

  • Использование веб-сайта также позволяет сделать пользовательский интерфейс более совместимым с реальными веб-сервисами и несколько проще реализовать его в приложениях, чем изобретать новый собственный метод многоэтапной аутентификации.

    (Сравните с SSH, у которого есть метод аутентификации «KeyboardInteractive», который может отображать несколько запросов с произвольным текстом — работает нормально для базового пароля+OTP или пары ключей+OTP, но в целом он довольно неуклюж, когда дело доходит до 2FA. Многие корпорации фактически заканчивают внедрение систем, использующих кратковременные пары ключей SSH, что очень похоже на токены OAuth2 или билеты Kerberos — вы проходите аутентификацию через корпоративный веб-сайт SSO, чтобы получить ключ SSH на день.)

• Токен, выданный вашему почтовому клиенту, имеет доступ только к определенным службам (областям), в данном случае IMAP и SMTP — например, его нельзя использовать для доступа к вашим файлам на Диске или вашей истории YouTube.

  • Хотя это может привести к злоупотреблениям со стороны поставщика услуг (например, Google требует дорогостоящей «проверки» для приложений OAuth2, которые имеют более 100 пользователей и хотят получить доступ к областям, связанным с почтой).

  • Создаваемые вручную «пароли приложений» также могут быть ограничены определенными сервисами, но мало кто будет эффективно использовать эту функцию – например, это возможно с помощью токенов доступа GitHub, но требуется слишком много умственных усилий, чтобы определить (часто методом проб и ошибок), какие Для какого приложения необходимы области действия, поэтому будет создано много токенов со всеми возможными областями действия...

У поставщика услуг также есть некоторые преимущества «глубокоэшелонированной защиты»:

• Фактическая служба никогда не получает ваш действительный пароль (и даже токен обновления — только кратковременный токен доступа), поэтому даже если одна служба скомпрометирована, она не сможет собрать учетные данные для доступа к другим службам («боковое перемещение»?).

  • Это очень похоже на использование билетов Kerberos в Active Directory или утверждений SAML в корпоративных системах единого входа.

    Во всех таких системах вместо всех служб, требующих доступа к базе данных пользователей (и все они являются ценными целями), у вас остается только KDC или IdP, находящийся в привилегированном положении.