Как работает авторизация пользователей

Если вы новичок или не знакомы со службами идентификации Google или авторизацией, начните с прочтения обзора .

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

Области только аутентификации

Несколько областей используются только для аутентификации пользователя: email , profile и openid . Если ваше приложение использует только эти области, подумайте, соответствует ли вашим потребностям токен идентификатора JWT и вход через Google для регистрации и входа пользователей. В большинстве случаев это самый простой и понятный метод аутентификации пользователя.

Ключевые термины и понятия

В этих руководствах предполагается, что у вас есть базовое понимание концепций OAuth 2.0 и стандартов IETF, таких как RFC6749 . В руководствах по авторизации используются следующие термины:

  • Токен доступа — это кратковременные учетные данные для каждого пользователя, выдаваемые Google и используемые для безопасного вызова API Google и доступа к пользовательским данным.
  • Код авторизации – это временный код, выдаваемый Google для безопасной идентификации отдельных пользователей, которые входят в свою учетную запись Google из браузера. Ваша серверная платформа обменивает этот код на токены доступа и обновления.
  • Токен обновления — это долгосрочные учетные данные для каждого пользователя, выданные Google, которые надежно хранятся на вашей платформе и могут использоваться для получения нового действительного токена доступа, даже если пользователь отсутствует.
  • Область действия ограничивает токены определенным и ограниченным объемом пользовательских данных. Дополнительные сведения см. в разделе «Области действия OAuth 2.0 для API Google ».
  • Режим всплывающего окна — это поток кода авторизации, основанный на обратном вызове JavaScript, выполняемом в браузере пользователя. Google вызывает ваш обработчик обратного вызова, который затем отвечает за отправку кода аутентификации на вашу платформу. Как это сделать, зависит от вас.
  • Режим перенаправления — это поток кода авторизации, основанный на перенаправлении HTTP. Пользовательский агент сначала перенаправляется в Google, второе перенаправление из Google в конечную точку кода авторизации вашей платформы включает этот код.

Срок действия токена устанавливается Google как эмитентом. В зависимости от различных факторов точная продолжительность может варьироваться.

Потоки OAuth 2.0

Обсуждаются два потока: неявный и код авторизации. Оба возвращают токен доступа, подходящий для использования с API Google.

Рекомендуется использовать поток кода авторизации, поскольку он обеспечивает повышенную безопасность пользователя. Этот поток также возвращает токен обновления, который можно использовать для получения токенов доступа без присутствия пользователя, что позволяет вашей платформе более легко выполнять асинхронные действия, такие как отправка SMS-напоминания о предстоящем собрании, которое было запланировано в последнюю минуту. Выбор модели авторизации объясняет различия между двумя потоками более подробно.

Библиотека JavaScript Google Identity Services соответствует стандарту OAuth 2.0 и позволяет:

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

Общие шаги

Поток неявного кода и кода авторизации начинается одинаково:

  1. Ваше приложение запрашивает доступ к одной или нескольким областям.
  2. Google отображает пользователю диалоговое окно согласия и, при необходимости, сначала регистрирует пользователя в своей учетной записи Google.
  3. Пользователь индивидуально утверждает каждую запрошенную область действия.

Затем каждый поток завершается разными шагами.

При использовании неявного потока

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

При использовании потока кода аутентификации

  • Google отвечает кодом авторизации для каждого пользователя:
    • В режиме перенаправления код возвращается в конечную точку кода авторизации вашей платформы.
    • Во всплывающем режиме код возвращается в обработчик обратного вызова вашего браузерного приложения, и пользователям не нужно покидать ваш веб-сайт.
  • Начиная с шага 4. Обработка ответа сервера OAuth 2.0, ваша серверная платформа завершает межсерверный обмен с Google, в результате чего на вашу платформу возвращается токен обновления для каждого пользователя и токен доступа.

Прежде чем получить токен доступа, отдельные пользователи должны предоставить вашему приложению согласие на доступ к запрошенным областям. Для этого Google отображает диалоговое окно согласия на шаге 2 выше и записывает результат в myaccount.google.com/permissions .

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

На рисунке 1 показано диалоговое окно согласия для одной области. Если запрашивается одна область, флажки для утверждения или отклонения области не требуются.

User consent dialog with Cancel or Continue buttons and a single scope, no
checkboxes are shown.

Рисунок 1. Диалоговое окно согласия пользователя с одной областью действия.

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

User consent dialog with Cancel or Continue buttons and multiple scopes, each
scope has a checkbox
selector.

Рисунок 2. Диалоговое окно согласия пользователя с несколькими областями действия.

Учетные записи пользователей

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

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

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

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

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

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

Пользователи могут просмотреть или отозвать согласие в любое время в настройках своей учетной записи Google.

При желании ваше веб-приложение или платформа может вызвать google.accounts.oauth2.revoke для отзыва токенов и согласия пользователя, что полезно, когда пользователь удаляет свою учетную запись с вашей платформы.

Другие варианты авторизации

Альтернативно, браузеры могут получать токены доступа, используя неявный поток, напрямую вызывая конечные точки Google OAuth 2.0, как описано в OAuth 2.0 для клиентских веб-приложений .

Аналогично, для потока кода авторизации вы можете реализовать свои собственные методы и выполнить действия, описанные в разделе «Использование OAuth 2.0 для приложений веб-сервера ».

В обоих случаях мы настоятельно рекомендуем использовать библиотеку Google Identity Services, чтобы сократить время и усилия на разработку, а также свести к минимуму риски безопасности, подобные тем, которые описаны в передовой текущей практике безопасности OAuth 2.0 .