Почему вы должны использовать сторонний вход (OAuth) для своего веб-приложения

OAuth избавляет от необходимости хранить конфиденциальные пароли пользователей на вашем сервере. Вместо этого пользователь доверяет вам доступ к основной информации своего профиля из такой службы, как Google, которая выполняет аутентификацию для вас.

Сторонний вход в систему освобождает вас от обработки паролей

Сторонний вход — это альтернатива аутентификации по имени пользователя/паролю. Вы определенно сталкивались с этим раньше, если вас когда-либо просили войти в систему с помощью Google или Facebook — вы просто аутентифицируетесь со своим профилем в социальной сети, не вводя никаких паролей.

Легче говорить о проблемах с альтернативами. Если вы не хотите использовать стороннюю аутентификацию, вам придется справиться со всем этим самостоятельно. Это означает, что вы будете нести ответственность за хранение паролей ваших пользователей, что возможно, если они должным образом засолены и хэшированы. Но это хлопотно, и вы не хотите нести ответственность за любую потенциальную утечку данных, связанную с паролями, даже если они хранятся должным образом.

Сторонний вход исключает вероятность этого, потому что вы никогда не будете обрабатывать что-либо личное. Эта работа остается за Google, Facebook и любым другим провайдером OAuth. Даже если вся ваша серверная сеть будет скомпрометирована, у вас не будет доступа ни к чему, кроме общедоступных профилей в социальных сетях.

В чем недостаток?

Теоретически OAuth ничем не отличается от аутентификации по паролю; это просто другой способ входа в систему. Но на практике OAuth вызывает несколько проблем.

Во-первых, вы должны доверять поставщику OAuth для безопасной обработки данных вашего пользователя. Однако на самом деле это не ваша проблема, поскольку любое нарушение на их стороне не влияет на ваш сервис. Но контроль над входом пользователей в систему передается провайдеру, что может не устраивать некоторых людей.

Пользователь также должен доверять вам при аутентификации у провайдера, а также должен иметь учетную запись у одного из провайдеров. Решение этой проблемы состоит в том, чтобы предложить несколько провайдеров; пользователь может не захотеть регистрироваться со своей учетной записью Facebook, но он может быть в порядке, регистрируясь со своей учетной записью Gmail.

Однако это создает еще одну проблему, уникальную для OAuth — пользователи могут случайно создать несколько учетных записей. Часто процесс регистрации такой же, как и вход в систему, потому что он обрабатывается в одном и том же потоке. Это может привести к тому, что пользователи забудут, под какой учетной записью они зарегистрировались, и случайно зарегистрируют новую учетную запись. Это может даже быть нарушением GDPR, если с этим не обращаться должным образом. Вы должны убедиться, что «Регистрация» и «Вход» обрабатываются отдельно.

Как это работает?

Сторонний вход использует OAuth 2.0 для аутентификации. OAuth — это набор стандартов, и существует множество различных потоков OAuth для разных вариантов использования. Наиболее распространенным из них, используемым для входа через социальные сети, является поток кода авторизации.

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

Если пользователь соглашается, Google перенаправляет его на URL-адрес обратного вызова с кодом авторизации.

Этот код авторизации действует как ключ к учетной записи пользователя. Хотя это не совсем ключ; это больше похоже на долговую расписку, где клиент подтверждает, что серверу разрешен доступ к учетной записи. Его разрешено использовать только вашему серверу.

Он используется только один раз, так как ваш сервер немедленно передаст ключ в Google, чтобы получить токен доступа и токен идентификатора, который используется для фактического доступа к учетной записи пользователя. При желании вы можете запросить токен обновления, чтобы обновить токен доступа после истечения срока его действия, не запрашивая у пользователя другой код авторизации.

В этом потоке вы запрашиваете доступ только для просмотра основной информации профиля, чтобы вы могли идентифицировать пользователя. Это называется вашей областью, которая представляет собой объем данных и количество функций, к которым у вас есть доступ. У каждого поставщика OAuth разные области действия (вот список Google), и вы также можете использовать OAuth для административного доступа к учетным записям, например службам, которым потребуется доступ к почтовому ящику пользователя или учетной записи Google Диска.

Как мне это настроить?

В этом примере мы будем использовать библиотеки Google OAuth, так как их просто настроить. Но Facebook, Github и Twitter также являются популярными провайдерами OAuth, и было бы неплохо внедрить в свое приложение хотя бы двух провайдеров. А если вы разрабатываете приложение для iOS, вам необходимо внедрить Apple в качестве поставщика OAuth с помощью их программы Sign In With Apple (если вы изначально используете стороннюю регистрацию).

Сначала перейдите в консоль Google API и создайте новый проект. Выберите «Веб-браузер» в качестве типа клиента и укажите исходный URL-адрес.

Затем включите библиотеку платформы Google в качестве скрипта на свой сайт:

<script src="https://apis.google.com/js/platform.js" async defer></script>

И включите свой идентификатор клиента в качестве метатега в заголовок вашего сайта:

<meta name="google-signin-client_id" content="YOUR_CLIENT_ID.apps.googleusercontent.com">

Вы можете реализовать кнопку самостоятельно или использовать готовую:

<div class="g-signin2" data-onsuccess="onSignIn"></div>

function onSignIn(googleUser) {
  var profile = googleUser.getBasicProfile();
  console.log('ID: ' + profile.getId()); // Do not send to your backend! Use an ID token instead.
  console.log('Name: ' + profile.getName());
  console.log('Image URL: ' + profile.getImageUrl());
  console.log('Email: ' + profile.getEmail()); // This is null if the 'email' scope is not present.
}

Если вы выполняете дальнейшую аутентификацию на внутреннем сервере, вы захотите отправить токены идентификатора, а не информацию профиля, поскольку они могут быть проверены сервером.

Если вы не хотите настраивать это самостоятельно, вы можете использовать Auth0, который бесплатен для 7000 пользователей в месяц, а также поддерживает Touch ID и двухфакторную аутентификацию. Или вы можете использовать другую библиотеку, например react-google-login, которая будет обрабатывать этот процесс в приложении React.