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

Оптимизируйте свои подборки Сохраняйте и классифицируйте контент в соответствии со своими настройками.

Если вы новичок или не знакомы с Google Identity Services или авторизацией, начните с чтения Обзора .

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

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

Несколько областей используются только для аутентификации пользователя: email , profile и openid . Если ваше приложение использует только эти области, подумайте, соответствуют ли вашим потребностям JWT ID Token и Sign In With 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» для регистрации и входа в веб-приложение или серверную платформу. Это снижает трение пользователей, сводя к минимуму количество необходимых шагов, и дополнительно позволяет легко связать токены доступа с отдельными учетными записями на вашей платформе.

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

Добавление подсказки во время инициализации авторизации — обычно адрес электронной почты учетной записи Google пользователя — позволяет Google пропустить отображение средства выбора учетной записи, экономя пользователям шаг. Учетные данные ID Token, возвращаемые функцией 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 .