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

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

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

Области действия, допускающие только аутентификацию

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

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

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

  • Токен доступа — это кратковременные учетные данные пользователя, выдаваемые Google, которые используются для безопасного вызова API Google и доступа к данным пользователя.
  • Код авторизации — это временный код, выдаваемый Google для безопасной идентификации отдельных пользователей, входящих в свою учетную запись Google через браузер. Ваша серверная платформа обменивает этот код на токены доступа и обновления.
  • Токен обновления — это долгосрочные учетные данные пользователя, выданные Google, которые надежно хранятся на вашей платформе и могут быть использованы для получения нового, действительного токена доступа, даже когда пользователь отсутствует.
  • Параметр Scope ограничивает объем пользовательских данных определенным количеством токенов; подробнее см. в разделе «Области действия 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 пропустить отображение окна выбора учетной записи, экономя пользователям один шаг. Учетные данные ID Token, возвращаемые функцией «Вход с помощью Google», содержат адрес электронной почты пользователя.

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

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

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

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

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

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

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

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