Id client: Что такое Client ID в Google Analytics

alexxlab

Содержание

Client ID и User ID

Уникальные пользователи, новые и вернувшиеся, каналы трафика и показатели конверсии — любой вопрос к системе аналитики начинается с малого — с идентификации пользователя. Для этого используются Client и User ID.

Что такое Client ID

Client ID — это анонимный идентификатор браузера. Система аналитики формирует его, чтобы опознавать уникальных пользователей и связывать действия каждого из них друг с другом.

Другими словами, когда система аналитики — Google Analytics или Яндекс.Метрика — формирует отчет по уникальным посетителям сайта, то имеет в виду именно количество уникальных браузеров, которым присвоен Client ID. Если один человек зашел на сайт с двух разных устройств или браузеров — в отчете будет отражено два уникальных посетителя. Если четыре человека зашли на сайт с одного браузера в течение короткого времени — для системы аналитики это будет один посетитель с четырьмя сессиями.

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

Client ID представляет собой набор цифр, записанных в файл cookie.

В Google Analytics он выглядит так: _ga=GA1.1.1135380329.1543226534

  • _ga — название cookie;

  • GA1 — универсальная часть для всех cookies подобного формата;

  • цифра 1 указывает на уровень домена, в данном случае это домен верхнего уровня;

  • первый блок из десяти цифр — число, сгенерированное случайным образом;

  • последняя часть — время создания cookie в формате UNIX.

А так в Яндекс.Метрике: _ym_uid=1543226534123620835

  • _ym_uid — название cookie;

  • первые десять цифр — время создания cookie в формате UNIX;

  • вторые десять цифр — число, сгенерированное случайным образом.

Можно заметить, что хоть формат записей и отличается, часть Client ID в обеих системах аналитики совпадает — 154322653. Верно, ведь обе cookie были взяты с одной страницы, на которой установлено два кода отслеживания. А значит, время создания Client ID в обеих системах одинаково. Хотя и не исключены ситуации, когда скрипты сработали с разницей в секунды — в таком случае последняя цифра будет отличаться.

Сколько хранится такой cookie-файл? Вопрос с подвохом. Еще недавно ответить на него было просто — он хранился два года с момента последнего визита или период, установленный в настройках браузера. Сейчас же браузеры начали существенно ограничивать срок жизни cookie-файлов. Например, в новом Safari они хранятся только две недели, независимо от настроек сайта. Это означает, что если посетитель зашел на сайт с разницей в 16 дней, то для системы аналитики это уже два разных пользователя, так как при втором посещении предыдущего cookie уже нет и браузер записал новый файл.

Где искать Client ID в отчетах аналитики

В Google Analytics в отчете «Аудитория» — «Статистика по пользователям» можно увидеть идентификаторы посетителей сайта, а также количество сессий, показатель отказов, транзакции, доход и коэффициент конверсии по каждому пользователю.

Чтобы увидеть более детальную информацию о посетителе и о каждом его действии, нужно кликнуть по определенному Client ID.

 

 

По умолчанию Client ID доступен только в этом отчете Google Analytics. В него можно добавлять сегменты, но он не сможет сгруппировать Client ID с другими параметрами, например источниками и каналами трафика, устройствами, URL перехода и т. д. Чтобы получить доступ к идентификатору в других отчетах Google Analytics, нужно дополнительно передавать Client ID в качестве пользовательского параметра, например, через функцию customTask. Подробную инструкцию к тому, как это сделать, можно прочитать в блоге OWOX.

В Яндекс.Метрике не нужно специально настраивать передачу Client ID, достаточно в отчете нажать кнопку «Группировки» и выбрать «Аудитория > Client ID» и увидеть отчет по конкретным пользователям.

Также можно использовать Client ID как условие сегментации.

Что такое User ID

Если Client ID — это уникальный анонимный идентификатор браузера, то User ID — это уникальный идентификатор пользователя в вашей внутренней системе, который пользователь получил при регистрации.

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

У User ID нет единого стандартного вида — его нужно присваивать самостоятельно на стороне сайта, и затем передавать в системы аналитики.

Настройка User ID в Google Analytics

Чтобы начать использовать User ID, нужно активировать эту функцию для аккаунта:

  1. Во вкладке «Администратор» выбрать нужный Ресурс.

  2. В Ресурсе выбрать «Отслеживание» — «User ID» — «Включить».

Нужно доработать код отслеживания Google Analytics или настройки тега Google Analytics с помощью Google Tag Manager, передавая в него UserID, который выдает бекенд сайта. Подробнее о том, как это сделать — читайте в справке Google. И наконец, нужно создать отдельное представление с User ID.

В результате появится несколько новых отчетов. Например, в разделе «Аудитория» — «Разные устройства» — «Пересечение устройств», «Пути устройств», «Устройство — источник трафика».

Отчет «Пересечение устройств» в Google Analytics

Все ли так хорошо, как кажется? Нет. Дело в том, что в представлении, где включен User ID, будут показаны только пользователи с User ID. То есть, если пользователь не идентифицирован, и у него есть только Client ID, он не попадет в эти отчеты. Создать же представление, где были бы и пользователи, и браузеры невозможно. В итоге получается, что в представлении с Client ID данные не совсем точные (нельзя быть уверенным, что браузер = конкретный пользователь; куки могли устареть и часть данных уже утеряна), а в представлении с User ID есть далеко не все пользователи.

Понимая эти особенности, каждый маркетолог сам решает для себя, как ему использовать данные обоих представлений. Лучшим решением здесь могло бы быть — собирать сырые данные и самостоятельно объединять действия пользователей.

Настройка User ID в Яндекс.Метрике

Передавать идентификатор посетителя в Яндекс.Метрику можно во время посещения сайта и с помощью загрузки файла .csv. В первом случае используется JavaScript API, подробнее о настройке можно прочитать в справке Яндекс.Метрики.

Чтобы передать идентификатор, загрузив CSV-файл, достаточно перейти в раздел «Настройка» — «Загрузка данных» — «Загрузка параметров посетителей» — в типе файла выбрать «User ID» — «Загрузить данные».

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

Итого

Client ID автоматически присваивается системой аналитики и идентифицирует браузер, а не человека. User ID присваивается на стороне сайта или CRM. Это тот параметр пользователя, по которому можно объединить всю доступную о нем информацию: поведение на сайте, имя, телефон, email, номер карты лояльности — и связать все его действия в разных браузерах и на разных устройствах. По сути, User ID — это то, с чего начинается настоящая аналитика.

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

Client ID в Google Analytics

Google Analytics

Google Tag Manager

Материал обновлен:

17:02:2021

Комментарии:

14

Что такое Client ID и зачем он необходим Google Analytics. Об этом и не только в материале

Что такое Client ID Google Analytics

Client ID (еще называют cid) – уникальный идентификатор, который присваивает Google Analytics вашему браузеру, когда вы переходите на сайт. Если ранее вы были на нем, то именно по значению Client ID система понимает, что вы делали ранее на этом сайте.

С помощью Client ID Google Analytics объединяет различные сеансы в одного пользователя. Также он используется при передачи данных из различных систем в Google Analytics через Measurement Protocol, например, из CRM и позволяет связать это действие с одной из сессий.

Где находится Client ID

Найти Client ID можно у себя в браузере если перейти в режим разработчика, затем на вкладку Application, после выбрав Cookies. Найдите в списке cookie файл с именем _ga – в нем хранится необходимое значение:

Значение Client ID в cookie

Сам идентификатор это значение в виде большого набора цифр разделенных точкой:

1787526689.1613540746

Отчет по Client ID в Google Analytics

Ознакомится с отчетом по Client ID можно выбрав раздел Аудитория отчет Статистика по пользователям:

Отчет по Client ID

Выбираем в списке интересующий идентификатор (например, при оформлении заказа вы зафиксировали Client ID в своей CRM системе) и получаем подробную информацию о посетителе сайта:

Пример отчета по конкретному Client ID

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

Фиксация Client ID через специальный параметр

Решение задачи можно разделить на два блока:

  • создание параметра в Google Analytics
  • настройка передачи значения в этот параметр

Для того, чтобы создать специальный параметр (еще называется пользовательский параметр) переходим к настройкам Google Analytics, на уровне ресурса выбираем следующий пункт меню:

Управление на уровне ресурса

Далее нажимаем на кнопку:

Добавить параметр

Заполняем форму создания параметра следующими значениями:

Настройка специального параметра

Знаю, что многие используют Область действия как Пользователь. Не думаю, что есть принципиальная разница в этой ситуации. После создания появится сообщение, в котором нужно запомнить индекс нового параметра, в моем случае это 15:

Параметр создан

Теперь переходим к передаче значения в этот параметр. В зависимости от того, какой вариант внедрения вы используете (через код отслеживания или через Google Tag Manager) нужно выбрать решение.

На сегодняшний день самым лучшим решением является использование customTask, его и реализуем.

Вариант для кода отслеживания Google Analytics (версия Universal). Потребует изменение кода счетчика, который предлагается по умолчанию – необходимо в него добавить следующую конструкцию:

ga(‘set’, ‘customTask’, function(tracker) {

   tracker.set(‘dimensionN’, tracker.get(‘clientId’));

});

В dimensionN необходимо N заменить на индекс созданного специального параметра, выше я создал его и ему присвоен индекс 15, значит для меня верным значением будет dimension15 . После внесения изменений код выглядит следующим образом:

(function(i,s,o,g,r,a,m){i[‘GoogleAnalyticsObject’]=r;i[r]=i[r]||function(){

(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),

m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)

})(window,document,’script’,’https://www.google-analytics.com/analytics.js’,’ga’);

ga(‘create’, ‘UA-XXXXX-X’, ‘auto’);

ga(‘set’, ‘customTask’, function(tracker) {

   tracker.set(‘dimension15’, tracker.get(‘clientId’));

});

ga(‘send’, ‘pageview’);

Вариант для Google Tag Manager. Способ настройки я описал в отдельной статье: Фиксация Client Id в Google Tag Manager.

Ранее, до появления customTask использовалось еще одно решение, но на сегодняшний день оно морально устарело.

Как настроить Client ID для Google Analytics 4

Если вы выполнили настройку импорта данных в Big Query из Google Analytics 4, то соответствующее значение можно найти в поле user_pseudo_id:

user_pseudo_id в Google Analytics 4

Передача Client ID в CRM

Значение, которое хранится в Client ID можно использовать для связи действий пользователя на сайте и за его пределами. Например, имея значение Client ID в вашей CRM системе вы сможете изучить поведение пользователя до того, как получили о нем запись как о потенциальном клиенте.

Зафиксировать его необходимо в тот момент, когда пользователь отправляет данные (форма заказа или регистрации) и они обрабатываются вашей CRM. Необходимое значение можно получить непосредственно из трекера Google Analytics с помощью кода:

function(){

  var tracker = ga.getAll()[0];

  return tracker.get(‘clientId’)

}

Немного поясню, что он делает. Сначала мы получаем трекер Google Analytics, затем методом get() через него получаем нужное нам значение. Еще один вариант – получить значение из cookie файла с именем _ga. Эту задачу необходимо поставить вашим разработчикам или обратиться к интеграторам CRM.

Client ID в Google Analytics 4

Рабочий способ передачи уникального идентификатора пользователя (Client ID) в Google Analytics 4  через Google Tag Manager.

Пока я переписывался с технической поддержкой Google (на протяжении месяца) по поводу принудительного изменения типа данных в Google Analytics 4 и готовил материал по Client ID, Симо Ахава (Simo Ahava) выпустил публикацию на эту тему, подтвердил в ней возникшую и у меня проблему, а также предложил интересное решение. Поэтому данная статья будет основана на его способе передачи уникального идентификатора пользователя (Client ID) в GA4, но с моими комментариями.

Итак, с переходом на GA4 у многих интернет-маркетологов встал вопрос переноса настроек из Universal Analytics в новый счетчик Аналитики. В том числе и отслеживание уникального идентификатора пользователя. Client ID (он же cid) — одна из тех метрик, которая необходима для настройки «сквозной аналитики» и на основе которой счетчики веб-аналитики связывают действия пользователей (1 конкретный браузер — 1 конкретное устройство = 1 файл cookie).

Несколько материалов в блоге по настройке Client ID для Universal Analytics и Яндекс.Метрики я публиковал ранее. Рекомендую к прочтению:

Чтобы просмотреть все действия, которые совершал пользователь на вашем сайте, вы можете воспользоваться отчетом Статистика по пользователям. Он находится в разделе Аудитория.

Отчет «Статистика по пользователям» в Universal Analytics

В Universal Analytics параметр, отвечающий за Client ID, называется Идентификатор клиента. Если вы подведете курсор мыши к вопросительному знаку, то увидите его определение: A unique ID that Analytics assigns to each device from which users engage your content (Уникальный идентификатор, который Google Analytics присваивает каждому устройству, с которого пользователи взаимодействуют с вашим контентом).

Открыв конкретный профиль, вы сможете посмотреть все действия этого пользователя (сеансы, их длительность, хиты, события и транзакции):

Профиль пользователя с определенным идентификатором клиента (Client ID) в Universal Analytics

В Google Analytics 4 в центре анализа (Analysis Hub) доступен шаблон Статистика пользователей:

Методики — Статистика пользователей

Создав его, вы увидите схожий с Universal Analytics отчет:

Отчет «Статистика по пользователям» в Google Analytics 4

В Google Analytics 4 параметр, отвечающий за Client ID, называется Идентификатор экземпляра приложения (App-instance ID). Если вы подведете курсор мыши к вопросительному знаку, то увидите его определение: A unique, user-resettable ID for advertising. Device ID corresponds to Advertising ID on Android and Identifier for Advertisers on iOS (Уникальный сбрасываемый идентификатор для показа рекламы. Идентификатор устройства соответствует рекламному идентификатору на Android и идентификатору рекламодателя (IDFA) на iOS). Написано сложно, но это все тот же уникальный идентификатор клиента (устройства).

Открыв конкретный профиль в GA4, вы увидите все действия этого пользователя, точно также, как и в Universal Analytics (сеансы, их длительность, хиты, события и транзакции):

Профиль пользователя с определенным идентификатором клиента (Client ID) в Google Analytics 4

В Universal Analytics мы для того, чтобы использовать Client ID в других отчетах (не только в Статистика по пользователям), создавали специальный параметр и методом customTask (как наиболее приоритетным и точным) передавали cid в UA.

К сожалению, метод customTask в GA4 не поддерживается. Поэтому нам необходимо использовать другой вариант передачи данных. Я предлагаю использовать тот, который описал Симо в своем блоге.

Для этого перейдите в Google Tag Manager и в галерее шаблонов сообщества найдите тег с именем GTAG GET API:

Тег GTAG GET API

Добавьте его в рабочую область с помощью соответствующей кнопки. В завершение нажмите Добавить.

Тег GTAG GET API от Симо позволяет получать различные значения из gtag.js (включая значения, заданные с помощью команды set), записывать их в уровень данных (dataLayer) и использовать эти данные в тегах других поставщиков. Подробнее про API gtag.js читайте в официальной документации Google.

Настройки тега GTAG GET API

В открывшемся окне с настройками тега задайте идентификатор счетчика GA4 в поле Measurement ID. Поскольку нас интересует уникальный идентификтор клиента, галочку Default Fields To Get — Client ID (client_id) оставьте активной.

Конфигурация тега GTAG GET API

Сохраните тег без триггера. Теперь необходимо зайти в сам тег Google Аналитика: конфигурация GA 4 и в расширенных настройках добавить порядок активации тегов, поставив галочку напротив Активировать тег после тега [Название вашего тега] и выбрав тег GTAG GET API из раскрывающегося списка:

Порядок активации тегов

Используя порядок активации тегов, вы гарантируете, что API не будет вызываться до тех пор, пока функция gtag() не будет загружена и инициализирована на странице. Сохраните изменения.

Когда вы откроете режим предварительного просмотра, вы увидите новое событие gtagApiGet. Если вы его не видите, скорее всего, это связано с тем, что на странице нет тега с конфигурацией GA4 или потому, что тег API сработал до того, как gtag() успел загрузиться.

Событие gtagApiGet

Затем создайте:

— триггер с именем события gtagApiGet;

Пользовательское событие gtagApiGet

— пользовательскую переменную типа Переменная уровня данных с именем переменной gtagApiResult.client_id

Переменная уровня данных gtagApiResult.client_id

Осталось только определиться с тем, как вы планируете передавать Client ID в Google Analytics 4. Вы можете создать специальный параметр (custom event dimension) или использовать свойство пользователя (user property). И в том и другом случае обязательно провести дополнительную настройку в интерфейсе GA4, создав или пользовательское определение, или свойство пользователя.

Например, задав такие имена в GA4: Настроить — Свойства пользователей — Создать свойство пользователя и События — Все события — Настроить пользовательские определения

Свойство пользователя и специальный параметр

Примечание: придумывайте такие имена, которые будут характеризовать отслеживаемую величину.

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

Пример конфигурации тега события

А вот теперь самое интересное! При передачи данных о Client ID пользователя режим отладки GTM и само значение переменной отображается корректно и имеет тип данных string (строка).

Значение Client ID имеет текстовый формат представления

Однако когда вы будете смотреть в отчеты Google Analytics 4, то увидите, что данные передались в измененном виде, а точнее формата double (число двойной точности). Вот как это будет выглядеть в GA4:

Измененный тип отображения Client ID

Есть предположение, что Google преобразует строковое представление числа в эквивалентное ему число двойной точности с плавающей запятой с помощью метода double.Parse. Но я не являюсь разработчиком, чтобы утверждать это со 100% точностью, и поэтому данный вопрос я задал техподдержке Google месяц назад.

Как оказалось, это не локальная проблема, и Симо в своей публикации это подтвердил. Ему удалось найти решение: всего лишь нужно добавить символ точки (.) в конце значения переменной. В моем примере — в двух местах (и для специального параметра, и для свойства пользователя):

Точка (.) в конце!

Сохраните изменения и не забудьте опубликовать новую версию контейнера GTM. Все!

Проверить корректность передачи данных можно с помощью инструмета DebugView.

DebugView

Как видите, в конце уникального идентификатора пользователя стоит точка (.). Она нужна для того, чтобы GA4 не преобразовывал эту строку в число.

В дальнейшем, если вы создали специальный параметр и свойство пользователя в интерфейсе Google Analytics 4, вы сможете использовать Client ID в отчетах центра анализа.

Пример переданного свойства пользователя в client_id_ga4

Клиент DigiDoc4 — ID.ee

  • Информация о версиях программного обеспечения ID-карты (release notes)

    ​ Kogu info ID-tarkvara viimaste versioonide, nendega seotud muudatuste, toetatud operatsioonisüsteemide ja võimalike puuduste kohta (ehk release notes).

  • В настройках клиента DigiDoc4 можно настроить мобильный идентификатор и доступ к услуге Smart-ID.

    Чтобы установить RPUUID, необходимый для доступа к службам Smart-ID и mobiil-ID: 1. Запустите клиентское приложение DigiDoc4. 2. Откройте «Настройки» в правом верхнем углу. 3. В разделе «Настройки» выберите «Услуги». 4. Установите RPUUID в поле «Мобильный идентификатор…

  • Ошибка клиента DigiDoc4: пожалуйста, проверьте часы на вашем компьютере
  • Ошибка клиента DigiDoc4: пожалуйста, проверьте часы на вашем компьютере

    В клиенте DigiDoc4 возникает ошибка, когда время компьютера, используемого для подписи, отличается от времени подтверждения действительности как минимум на 15 минут.

  • Как назначить TSA URL’i в DigiDoc4 клиенте?

    Инструкция о порядке назначения TSA URL’i в DigiDoc4 клиенте. 

  • Ошибки „Insert Smart Card“ и „No Certificates Available“ при аутентификации или подписании, DigiDoc4 уведомляет о том, что «Не найдено ни одной ID-карты»

    В случае, если при аутентификации или подписании видите ошибку „Insert Smart Card“, „No Certificates Available“ или DigiDoc4 выдает уведомление об ошибке «Не найдено ни одной карты», можете разрешить ситуацию с помощью данной инструкции.

  • Уведомление DigiDoc4: обновление списка доверия сертификатов не удалось

    Что делать, если уведомление об ошибке DigiDoc4 сообщает о том, что обновление списка доверия сертификатов не удалось.

  • Информация о последней версии ID-программы

    Информация о версии компонентов для самой последней версии ID-программы: для операционных систем Windows, macOS и Linux.

  • Почему необходимо обновлять ID-программу?

    Каждое программное обеспечение должно время от времени обновляться в целях обеспечения безопасности программного обеспечения и простоты использования. Всегда относитесь к обновлению ID-программу серьезно!

  • Известные недостатки ID-программы

    Каждая новая версия программного обеспечения DigiDoc4 стремится уменьшить число известных недостатков, но безопасность пользователя и его данных, а также надежность ПО всегда остается на первом месте.

    • client

    Во всех шаблонах кроме:

    можно получить только факт того что клиент зашел в свой личный кабинет:

    {% if client %}
<a href="/client_account/orders">Мой кабинет</a> | 
    <a href="/client_account/exit">Выйти</a> 
    {% else %} 
    <a href="/client_account/login">Войти</a> | 
    <a href="/client_account/contacts/new">Зарегистрироваться</a> 
    {% endif %}
    Скопировать

    В шаблонах order и account.orders доступны методы:

    • client.all_fields — массив всех дополнительных полей покупателя (в том числе НЕ выводимых покупателю)
    • client.client_fields — массив дополнительных полей покупателя с учетом настроек их показа покупателям
    • client.phone — телефон покупателя
    • client.name — имя клиента
    • client.surname — фамилия клиента
    • client.middlename — отчество клиента
    • client.full_name — строка, составленная из полей фамилии, имени и отчества клиента через пробел
    • client.email — е-мейл клиента
    • client.id — ID клиента
    • client.turnover — сумма выполненных (оплаченных) заказов (для залогиненных клиентов)
    • client.discount — объект Скидка клиента (на момент написания статьи это текущая накопительная скидка клиента)
    • client.next_level_discount — объект Скидка — ближайший уровень для следующей накопительной скидки
    • client.bonus_points — текущее количество бонусных баллов
    • client.bonus_system_transactions — массив транзакций списания и зачисления бонусных баллов

    Получите идентификатор клиента Google API | Войти через Google

    Чтобы включить вход с помощью Google на своем веб-сайте, сначала необходимо настроить Google Идентификатор клиента API. Для этого выполните следующие действия:

    1. Откройте страницу Credentials Консоль API Google.

    2. Создайте или выберите проект API Google. Если у вас уже есть проект для Войти с помощью кнопки Google или Google One Tap, использовать существующий проект и Интернет ID клиента.

      Если у вашего проекта нет идентификатора клиента типа веб-приложения, щелкните Создайте учетные данные> идентификатор клиента OAuth , чтобы создать его. Обязательно включите домен вашего сайта в поле Авторизованные источники JavaScript . Пожалуйста, обрати внимание что Google One Tap может отображаться только в доменах HTTPS. Когда вы выполняете локальные тесты или разработка, вы должны добавить как http: // localhost , так и http: // localhost: <номер_порта> в поле авторизованных источников JavaScript .

      Ключевой момент: Google One Tap может отображаться только в доменах HTTPS. Ключевой момент: Добавьте http: // localhost и http: // localhost: в поле авторизованных источников JavaScript для локальных тестов или разработка.

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

      1234567890-abc123def456.apps.googleusercontent.com

    Настройте экран согласия OAuth

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

    1. Откройте страницу с экраном согласия OAuth в консоли API Google.
    2. При появлении запроса выберите только что созданный проект.

    3. На странице «Экран согласия OAuth» заполните форму и нажмите кнопку «Сохранить».

      1. Название приложения: Название приложения, запрашивающего согласие. Имя должно точно отражать ваше приложение и соответствовать имени приложения, которое пользователи видят в другом месте. Название приложения будет отображаться в диалоговом окне «Одно касание».

      2. Логотип приложения: Изображение на экране согласия, которое поможет пользователям узнать ваше приложение. Логотип отображается на экране согласия «Войти с помощью Google» и в настройках учетной записи, но не отображается в диалоговом окне «В одно касание».

      3. Адрес электронной почты службы поддержки: Отображается на экране согласия для поддержки пользователей и для администраторов G Suite, оценивающих доступ своих пользователей к вашему приложению. Этот адрес электронной почты будет показан пользователям на экране согласия «Войти с помощью Google», когда пользователь щелкнет имя приложения.

      4. Области действия для API Google: Области позволяют вашему приложению получать доступ к личным данным Google вашего пользователя. Для аутентификации достаточно области по умолчанию (электронная почта, профиль, openid), вам не нужно добавлять какие-либо конфиденциальные области.Как правило, рекомендуется запрашивать области постепенно, в то время, когда требуется доступ, а не заранее. Учить больше.

      5. Авторизованные домены: Для защиты вас и ваших пользователей Google разрешает только приложениям, которые проходят аутентификацию с помощью OAuth, использовать авторизованные домены. Ссылки ваших приложений должны размещаться в авторизованных доменах. Учить больше.

      6. Ссылка на главную страницу приложения: Отображается при входе в систему с помощью экрана согласия Google и информации об отказе от ответственности в отношении претензий GDPR в одно касание под кнопкой «Продолжить как».Должен размещаться в авторизованном домене.

      7. Ссылка на Политику конфиденциальности приложения: Отображается при входе в систему с помощью экрана согласия Google и информации об отказе от претензий по GDPR в одно касание под кнопкой «Продолжить как». Должен размещаться в авторизованном домене.

      8. Ссылка на Условия использования приложения (необязательно): Отображается при входе в систему с помощью экрана согласия Google и информации об отказе от ответственности по жалобе GDPR одним нажатием под кнопкой «Продолжить как». Должен размещаться в авторизованном домене.

      Рисунок 1 . Поля экрана согласия OAuth, отображаемые в пользовательском интерфейсе One Tap

    4. Отметьте «Статус проверки». Если ваше приложение требует проверки, нажмите кнопку «Отправить на проверку», чтобы отправить заявку на проверку. Дополнительные сведения см. В требованиях к проверке OAuth.

    Использование OAuth 2.0 для доступа к API Google | Google Identity

    Примечание. Использование реализации OAuth 2 от Google.0 регулируется политики OAuth 2.0.

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

    Для начала получите учетные данные клиента OAuth 2.0 из Консоль Google API. Затем ваше клиентское приложение запрашивает токен доступа с сервера авторизации Google, извлекает токен из ответа и отправляет токен в API Google, к которому вы хотите получить доступ.Для интерактивной демонстрации использования OAuth 2.0 с Google (включая возможность использования ваших собственных учетных данных клиента), поэкспериментируйте с OAuth 2.0 Детская площадка.

    На этой странице представлен обзор сценариев авторизации OAuth 2.0, которые поддерживает Google. и предоставляет ссылки на более подробное содержание. Подробнее об использовании OAuth 2.0 для аутентификацию, см. OpenID Connect.

    Примечание: Учитывая последствия для безопасности получения реализации правильно, мы настоятельно рекомендуем вам использовать OAuth 2.0 библиотек при взаимодействии с Google Конечные точки OAuth 2.0. Рекомендуется использовать хорошо отлаженный код, предоставленный другими, и это поможет вам защитить себя и своих пользователей. Для получения дополнительной информации см. Клиентские библиотеки.

    Основные шаги

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

    1. Получите учетные данные OAuth 2.0 из консоли Google API.

    Посетите Консоль Google API для получения учетных данных OAuth 2.0, таких как клиент. Идентификатор и секрет клиента, известные как Google, так и вашему приложению. Набор ценностей зависит от типа создаваемого вами приложения. Например, JavaScript приложение не требует секрета, но приложение веб-сервера требует.

    2. Получите токен доступа от сервера авторизации Google.

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

    Есть несколько способов сделать этот запрос, и они различаются в зависимости от типа приложения. вы строите. Например, приложение JavaScript может запросить токен доступа, используя браузер перенаправляет на Google, а приложение, установленное на устройстве без браузера использует запросы веб-сервисов.

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

    Если пользователь предоставляет хотя бы одно разрешение, сервер авторизации Google отправляет ваш приложению токен доступа (или код авторизации, который ваше приложение может использовать для получить токен доступа) и список областей доступа, предоставленных этим токеном.Если пользователь не предоставляет разрешение, сервер возвращает ошибку.

    Обычно рекомендуется запрашивать области постепенно, в то время, когда требуется доступ, а не впереди. Например, приложение, которое хочет поддерживать сохранение события в календаре. не должен запрашивать доступ к календарю Google, пока пользователь не нажмет кнопку «Добавить в календарь»; видеть Инкрементальная авторизация.

    3. Изучите области доступа, предоставленные пользователем.

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

    Объем, включенный в ваш запрос, может не совпадать с объемом, указанным в вашем ответе, даже если пользователь предоставил все запрошенные области.См. Документацию по каждому API Google для области, необходимые для доступа. API может отображать несколько строковых значений области видимости в один область доступа, возвращая одну и ту же строку области для всех значений, разрешенных в запросе. Пример: API Google People может возвращать объем https://www.googleapis.com/auth/contacts , когда приложение запрашивает авторизацию пользователя. объем https://www.google.com/m8/feeds/ ; метод Google People API человек.обновить требуется предоставленная область https://www.googleapis.com/auth/contacts .

    4. Отправьте токен доступа в API.

    После того, как приложение получает токен доступа, оно отправляет токен в Google API в Заголовок запроса HTTP-авторизации. Можно отправлять токены как параметры строки запроса URI, но мы не рекомендуем это делать, поскольку параметры URI могут попадать в файлы журнала, которые не являются полностью безопасными.Кроме того, это хорошая практика REST, чтобы избежать создания ненужных имен параметров URI. Обратите внимание, что Поддержка строки запроса будет прекращена с 1 июня 2021 г.

    Токены доступа действительны только для набора операций и ресурсов, описанных в область запроса токена. Например, если маркер доступа выпущен для Google Calendar API, он не предоставляет доступ к Google Contacts API. Однако вы можете отправьте этот токен доступа в Google Calendar API несколько раз для аналогичных операций.

    5. При необходимости обновите токен доступа.

    Жетоны доступа имеют ограниченный срок жизни. Если вашему приложению требуется доступ к Google API за пределами срока жизни одного токена доступа он может получить токен обновления. Обновление token позволяет вашему приложению получать новые токены доступа.

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

    Сценарии

    Приложения веб-сервера

    Конечная точка Google OAuth 2.0 поддерживает приложения веб-сервера, которые используют языки и такие фреймворки, как PHP, Java, Python, Ruby и ASP.NET.

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

    Приложение должно хранить токен обновления для будущего использования и использовать токен доступа для получить доступ к Google API. По истечении срока действия токена доступа приложение использует токен обновления. получить новый.

    Подробнее см. Использование OAuth 2.0 для Интернета Серверные приложения.

    Установленные приложения

    Конечная точка Google OAuth 2.0 поддерживает приложения, установленные на таких устройствах, как компьютеры, мобильные устройства и планшеты. Когда вы создаете идентификатор клиента через Консоль Google API, укажите, что это установленное приложение, затем выберите Android, приложение Chrome, iOS, Универсальная платформа Windows (UWP) или классическое приложение в качестве типа приложения.

    Результатом процесса является идентификатор клиента и, в некоторых случаях, секрет клиента, который вы вставляете в исходный код вашего приложения.(В этом контексте секрет клиента явно не считается секретом.)

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

    Приложение должно хранить токен обновления для будущего использования и использовать токен доступа для получить доступ к Google API. По истечении срока действия токена доступа приложение использует токен обновления. получить новый.

    Подробнее см. Использование OAuth 2.0 для установленных приложений.

    Клиентские (JavaScript) приложения

    Конечная точка Google OAuth 2.0 поддерживает приложения JavaScript, которые запускаются в браузере.

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

    Результатом является маркер доступа, который клиент должен проверить перед включением его в Запрос Google API. Когда срок действия токена истекает, приложение повторяет процесс.

    Подробнее см. Использование OAuth 2.0 для клиентских приложений.

    Приложения на устройствах с ограниченным вводом

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

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

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

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

    Подробнее см. Использование OAuth 2.0. для устройств.

    Счета обслуживания

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

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

    Примечание: Эти сценарии учетной записи службы требуют, чтобы приложения создавать и криптографически подписывать веб-токены JSON (JWT). Мы настоятельно рекомендуем вам использовать библиотека для выполнения этих задач. Если вы напишете этот код без использования библиотеки, абстрагирует создание и подпись токена, вы можете допустить ошибки, которые могут серьезно повлиять на о безопасности вашего приложения.Список библиотек, поддерживающих этот сценарий, см. сервис-аккаунт документация.

    Учетные данные учетной записи службы, которые вы получаете от Консоль Google API, включите сгенерированный уникальный адрес электронной почты, идентификатор клиента и по крайней мере одну пару открытого / закрытого ключей. Вы используете идентификатор клиента и один частный ключ для создания подписанного JWT и построения запроса токена доступа в соответствующем формате. Затем ваше приложение отправляет запрос токена в Google OAuth 2.0 Сервер авторизации, который возвращает токен доступа. Приложение использует токен для доступа к Google API. Когда срок действия токена истекает, приложение повторяет процесс.

    Подробнее см. сервисно-учетная документация.

    Примечание: Хотя вы можете использовать учетные записи служб в приложения, которые запускаются из домена G Suite, сервисные аккаунты не являются членами вашей G Аккаунт Suite и не подпадают под правила домена, установленные администраторами G Suite.Для Например, политика, установленная в консоли администратора G Suite, ограничивает возможность завершения G Suite пользователи для совместного использования документов за пределами домена не будут применяться к учетным записям служб.

    Размер токена

    Токены могут различаться по размеру до следующих ограничений:

    • Коды авторизации: 256 байт
    • токенов доступа: 2048 байт
    • Жетоны обновления: 512 байт

    токенов доступа, возвращенных Google Cloud API службы токенов безопасности структурированы аналогично Google API OAuth 2.0 токенов доступа, но имеют другой размер токена пределы. Подробнее см. Документация по API.

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

    Срок действия токена обновления

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

    • У пользователя отозвал доступ вашему приложению.
    • Маркер обновления не использовался шесть месяцев.
    • Пользователь изменил пароли, и токен обновления содержит области Gmail.
    • Учетная запись пользователя превысила максимальное количество предоставленных (действующих) токенов обновления.
    • Пользователь принадлежит к организации Google Cloud Platform, в которой действуют политики управления сеансами.

    Проект Google Cloud Platform с экраном согласия OAuth, настроенным для внешнего тип пользователя и статус публикации "Тестирование" выдается токен обновления, срок действия которого истекает в 7 дней.

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

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

    Если вам нужно авторизовать несколько программ, машин или устройств, можно решить проблему. ограничьте количество клиентов, которых вы авторизуете для одной учетной записи Google, до 15 или 20. Если вы Администратор Google Workspace, вы можете создать дополнительных пользователей с административными привилегиями и использовать их для авторизации некоторые клиенты.

    Работа с политиками управления сеансами для организаций Google Cloud Platform (GCP)

    Администраторам организаций GCP может потребоваться частая повторная аутентификация пользователей во время они получают доступ к ресурсам GCP, используя Управление сеансом Google Cloud характерная черта.Эта политика влияет на доступ к Google Cloud Console, Google Cloud SDK (также известный как gcloud CLI) и любое стороннее приложение OAuth, для которого требуется область Cloud Platform. Если у пользователя есть политика управления сеансом, то по истечении срока действия сеанса ваш При вызове API произойдет ошибка, аналогичная тому, что произошло бы, если бы токен обновления был отозван - вызов завершится с ошибкой типа invalid_token ; тип под-ошибки может быть используется для различения токена отзыва и сбоя из-за политики управления сеансом.В качестве продолжительность сеанса может быть очень ограниченной (от 1 часа до 24 часов), этот сценарий должен быть обрабатывается изящно путем перезапуска сеанса аутентификации.

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

    Для получения дополнительной информации о том, как помочь вашим клиентам развернуть эту функцию, обратитесь к этому Справочная статья, ориентированная на администраторов.

    Клиентские библиотеки

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

    Создание приложения и субъекта-службы Azure AD на портале - платформа Microsoft Identity

    • 8 минут на чтение

    В этой статье

    В этой статье показано, как создать новое приложение Azure Active Directory (Azure AD) и субъект-службу, которые можно использовать с контролем доступа на основе ролей.Если у вас есть приложения, размещенные службы или автоматизированные инструменты, которым требуется доступ к ресурсам или их изменение, вы можете создать удостоверение для приложения. Это удостоверение известно как субъект-служба. Доступ к ресурсам ограничен ролями, назначенными субъекту службы, что дает вам контроль над тем, к каким ресурсам можно получить доступ и на каком уровне. По соображениям безопасности всегда рекомендуется использовать участников-служб с автоматизированными инструментами, а не разрешать им входить в систему с идентификатором пользователя.

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

    Важно

    Вместо создания субъекта-службы рассмотрите возможность использования управляемых удостоверений для ресурсов Azure для удостоверения вашего приложения.Если ваш код работает в службе, которая поддерживает управляемые удостоверения и обращается к ресурсам, поддерживающим проверку подлинности Azure AD, управляемые удостоверения - лучший вариант для вас. Чтобы узнать больше об управляемых удостоверениях для ресурсов Azure, в том числе о том, какие службы в настоящее время их поддерживают, см. Что такое управляемые удостоверения для ресурсов Azure ?.

    Регистрация приложений, объекты приложений и субъекты служб

    Невозможно напрямую создать субъект-службу с помощью портала Azure. Когда вы регистрируете приложение через портал Azure, объект приложения и субъект-служба автоматически создаются в вашем домашнем каталоге или клиенте.Дополнительные сведения о взаимосвязи между регистрацией приложения, объектами приложения и субъектами-службами см. В статье Объекты субъектов-служб и приложений в Azure Active Directory.

    Разрешения, необходимые для регистрации приложения

    У вас должны быть достаточные разрешения для регистрации приложения в клиенте Azure AD и назначения ему роли в подписке Azure.

    Проверьте разрешения Azure AD

    1. Выберите Azure Active Directory .

    2. Отметьте свою роль. Если у вас есть роль Пользователь , вы должны убедиться, что пользователи, не являющиеся администраторами, могут регистрировать приложения.

    3. На левой панели выберите Параметры пользователя .

    4. Проверьте настройки App Registrations . Это значение может установить только администратор. Если установлено значение Да , любой пользователь в клиенте Azure AD может зарегистрировать приложение.

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

    Проверьте разрешения подписки Azure

    В вашей подписке Azure ваша учетная запись должна иметь Microsoft.Авторизация / * / Запись доступа для назначения роли приложению AD. Это действие предоставляется через роль владельца или роль администратора доступа пользователей. Если вашей учетной записи назначена роль Contributor , у вас недостаточно прав. Вы получите сообщение об ошибке при попытке назначить роль субъекта-службы.

    Чтобы проверить разрешения на подписку:

    1. Найдите и выберите подписок или выберите подписок на домашней странице .

    2. Выберите подписку, в которой вы хотите создать субъект-службу.

      Если вы не видите искомую подписку, выберите глобальный фильтр подписок . Убедитесь, что для портала выбрана нужная подписка.

    3. Выберите Мои разрешения . Затем выберите Щелкните здесь, чтобы просмотреть полные сведения о доступе для этой подписки .

    4. Выберите Просмотреть в Назначения ролей , чтобы просмотреть назначенные роли и определить, есть ли у вас соответствующие разрешения для назначения роли приложению AD.Если нет, попросите администратора подписки добавить вас к роли администратора доступа пользователей. На следующем изображении пользователю назначается роль владельца, что означает, что у пользователя есть соответствующие разрешения.

    Зарегистрируйте приложение в Azure AD и создайте субъект-службу

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

    1. Войдите в свою учетную запись Azure через портал Azure.

    2. Выберите Azure Active Directory .

    3. Выберите Регистрации приложений .

    4. Выбрать Новая регистрация .

    5. Назовите приложение. Выберите поддерживаемый тип учетной записи, который определяет, кто может использовать приложение. В Redirect URI выберите Web для типа приложения, которое вы хотите создать. Введите URI, на который отправляется токен доступа. Вы не можете создать учетные данные для собственного приложения.Вы не можете использовать этот тип для автоматизированного приложения. После установки значений выберите Регистр .

    Вы создали приложение Azure AD и субъект-службу.

    Примечание

    Вы можете зарегистрировать несколько приложений с одним и тем же именем в Azure AD, но приложения должны иметь разные идентификаторы приложения (клиента).

    Назначьте роль приложению

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

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

    1. На портале Azure выберите уровень области, которой вы хотите назначить приложение.Например, чтобы назначить роль в области действия подписки, найдите и выберите Подписки или выберите Подписки на домашней странице .

    2. Выберите конкретную подписку, для которой нужно назначить приложение.

      Если вы не видите искомую подписку, выберите глобальный фильтр подписок . Убедитесь, что для портала выбрана нужная подписка.

    3. Выберите Контроль доступа (IAM) .

    4. Выберите Выбрать Добавить > Добавить назначение роли , чтобы открыть страницу Добавить назначение роли .

    5. Выберите роль, которую вы хотите назначить приложению. Например, чтобы разрешить приложению выполнять такие действия, как перезагрузка , запуск и остановка экземпляров, выберите роль Contributor . Подробнее о доступных ролях По умолчанию приложения Azure AD не отображаются в доступных параметрах.Чтобы найти свое приложение, найдите имя и выберите его.

      Назначьте приложению роль участника в рамках подписки. Подробные инструкции см. В разделе Назначение ролей Azure с помощью портала Azure.

    Ваш принципал обслуживания настроен. Вы можете начать использовать его для запуска своих скриптов или приложений. Чтобы управлять своим субъектом-службой (разрешения, разрешения, согласованные пользователем, посмотреть, какие пользователи дали согласие, просмотреть разрешения, просмотреть информацию для входа и т. Д.), Перейдите к Корпоративные приложения .

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

    Получить значения идентификатора клиента и приложения для входа в систему

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

    1. Выберите Azure Active Directory .

    2. Из регистраций приложений в Azure AD выберите свое приложение.

    3. Скопируйте идентификатор каталога (арендатора) и сохраните его в коде приложения.

      Идентификатор каталога (арендатора) также можно найти на странице обзора каталога по умолчанию.

    4. Скопируйте Application ID и сохраните его в своем коде приложения.

    Аутентификация: два варианта

    Для субъектов служб доступны два типа аутентификации: аутентификация на основе пароля (секрет приложения) и аутентификация на основе сертификатов. Мы рекомендуем использовать сертификат , но вы также можете создать секрет приложения.

    Вариант 1. Загрузить сертификат

    Вы можете использовать существующий сертификат, если он у вас есть. При желании вы можете создать самозаверяющий сертификат только для целей тестирования . Чтобы создать самозаверяющий сертификат, откройте PowerShell и запустите New-SelfSignedCertificate со следующими параметрами, чтобы создать сертификат в хранилище сертификатов пользователя на вашем компьютере:

      $ cert = New-SelfSignedCertificate -Subject "CN = DaemonConsoleCert" -CertStoreLocation "Cert: \ CurrentUser \ My" -KeyExportPolicy Exportable -KeySpec Signature

    Экспортируйте этот сертификат в файл с помощью оснастки MMC «Управление сертификатом пользователя», доступной из Панели управления Windows.

    1. Выберите Run из меню Start , а затем введите certmgr.msc .

      Появится инструмент диспетчера сертификатов для текущего пользователя.

    2. Для просмотра сертификатов в разделе Сертификаты - Текущий пользователь на левой панели разверните каталог Personal .

    3. Щелкните правой кнопкой мыши созданный сертификат, выберите Все задачи-> Экспорт .

    4. Следуйте указаниям мастера экспорта сертификатов.Не экспортируйте закрытый ключ, а экспортируйте его в файл .CER.

    Для загрузки сертификата:

    1. Выберите Azure Active Directory .

    2. Из регистраций приложений в Azure AD выберите свое приложение.

    3. Выберите Сертификаты и секреты .

    4. Выберите Загрузить сертификат и выберите сертификат (существующий сертификат или самозаверяющий сертификат, который вы экспортировали).

    5. Выбрать Добавить .

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

    Вариант 2. Создайте новый секрет приложения

    Если вы решите не использовать сертификат, вы можете создать новый секрет приложения.

    1. Выберите Azure Active Directory .

    2. Из регистраций приложений в Azure AD выберите свое приложение.

    3. Выберите Сертификаты и секреты .

    4. Выберите Секреты клиента -> Секрет нового клиента .

    5. Укажите описание секрета и продолжительность. Когда закончите, выберите Добавить .

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

    Настроить политики доступа к ресурсам

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

    1. На портале Azure перейдите в хранилище ключей и выберите Политики доступа .
    2. Выберите Добавить политику доступа , затем выберите ключ, секрет и разрешения сертификата, которые вы хотите предоставить своему приложению. Выберите субъект-службу, который вы создали ранее.
    3. Выберите Добавить , чтобы добавить политику доступа, затем Сохранить , чтобы зафиксировать изменения.

    Следующие шаги

    Создание идентификаторов клиентов | Платформы Cloud Endpoints для App Engine

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

    Android

    Чтобы создать идентификатор клиента OAuth 2.0 Android, вам потребуется отпечаток ключа сертификата. Если вы используете Android Studio, хранилище ключей отладки и ключ отладки создаются автоматически. Вы можете использовать ключ отладки для для тестирования, но вы должны использовать ключ выпуска для производства.

    Обратите внимание, что пароль хранилища ключей отладки по умолчанию - android , и псевдоним ключа - androiddebugkey . Расположение по умолчанию для Linux а macOS - ~ /.android / debug.keystore .

    Предупреждение: При создании ключа разблокировки не используйте android в качестве ключа разблокировки или пароля хранилища ключей.
    1. Если у вас его еще нет, сгенерируйте ключ отладки или выпуска для вашего Приложение для Android. Если вы используете Android Studio, он автоматически генерирует ключ отладки в хранилище ключей отладки при первой сборке проекта Android.
    2. В окне терминала Linux или macOS вы можете получить отпечаток key с помощью keytool , включенного в Java SDK, следующим образом:
       keytool -exportcert -alias androiddebugkey -keystore path-to-debug-or-production-keystore -list -v
      На выходе отображается отпечаток пальца, подобный следующему: DA: 39: A3: EE: 5E: 6B: 4B: 0D: 32: 55: BF: EF: 95: 60: 18: 90: AF: D8: 07: 09
    3. Скопируйте и сохраните отпечаток ключа, который отображается после выполнения предыдущего keytool команда.Вам необходимо предоставить отпечаток пальца сгенерируйте идентификатор клиента Android в Google Cloud Console.
    4. В облачной консоли перейдите на страницу Credentials .

      Перейти на страницу учетных данных

    5. В списке проектов выберите проект, содержащий ваш API.
    6. Если вы впервые создаете идентификатор клиента в этом проекте, используйте подэтапы для перехода на страницу согласия OAuth ; в противном случае переходите к следующему шаг.
      1. Щелкните Экран согласия OAuth .
      2. Введите имя в поле Имя приложения .
      3. Заполните остальные поля по мере необходимости.
      4. Нажмите Сохранить .
    7. В раскрывающемся списке Создать учетные данные выберите Идентификатор клиента OAuth .
    8. Выберите Android в качестве типа приложения.
    9. В поле Name введите имя для своего идентификатора клиента.
    10. В Signing-certificate fingerprint введите отпечаток пальца, который вы получено ранее.
    11. В Имя пакета введите имя пакета приложения Android, как указанный в вашем файле AndroidManifest.xml .
    12. Щелкните Create .

      Вы используете сгенерированный идентификатор клиента в своем API-интерфейсе и в своем клиенте. заявление.

    Веб-клиент

    1. В облачной консоли перейдите на страницу Credentials .

      Перейти на страницу учетных данных

    2. В списке проектов выберите проект, содержащий ваш API.
    3. Если вы впервые создаете идентификатор клиента в этом проекте, используйте подэтапы для перехода на страницу согласия OAuth ; в противном случае переходите к следующему шаг.
      1. Щелкните Экран согласия OAuth .
      2. Введите имя в поле Имя приложения .
      3. Заполните остальные поля по мере необходимости.
      4. Нажмите Сохранить .
    4. В раскрывающемся списке Создать учетные данные выберите Идентификатор клиента OAuth .
    5. Выберите Веб-приложение в качестве типа приложения.
    6. В поле Name введите имя для своего идентификатора клиента.
    7. В авторизованных источниках JavaScript введите одно из следующих значений:
      • http: // localhost: 8080 , если вы локальное тестирование серверной части.

      • https: // ИД_ ВАШЕГО ПРОЕКТА .appspot.com , замена YOUR_PROJECT_ID с идентификатором проекта App Engine, если вы развертываете backend API для вашего производственного App Engine.

        Важно: Вы должны указать сайт или имя хоста в поле Авторизованное происхождение JavaScript используя https для работы с конечными точками облака, если вы не тестируете localhost , в этом случае вы должны использовать http .
    8. Щелкните Create .

      Вы используете сгенерированный идентификатор клиента в своем API-интерфейсе и в своем клиенте. заявление.

    Что дальше?

    Для получения информации о поддержке аутентификации в вашем Android или Приложение JavaScript, см. Следующее:

    Что такое идентификатор клиента Google Analytics и чем он отличается от идентификатора пользователя

    Что такое идентификатор клиента Google Analytics?

    Идентификатор клиента Google Analytics представляет собой комбинацию уникального случайного числа и первой отметки времени (т.е.е. время первого посещения). Например: 58641932.1608012265

    Идентификатор клиента представляет собой уникальный браузер / устройство и создается и назначается файлом cookie Universal Analytics _ga. Идентификатор клиента присваивается каждому уникальному пользователю вашего сайта.

    Идентификаторы клиентов можно найти в отчете «User Explorer» (в разделе «Audience») в представлении отчетов GA.

    В контексте Google Analytics «Идентификатор клиента» и «Идентификатор пользователя» - это не одно и то же.

    Ниже приведены основные различия между «Client ID» и «User ID»:

    Разница № 1

    Client ID представляет собой уникальный браузер / устройство.

    User ID представляет уникального пользователя.

    Разница № 2

    Идентификатор клиента создается и присваивается файлом cookie Universal Analytics _ga .

    User ID создают и назначают такие люди, как я и вы.

    Разница № 3

    Client ID присваивается каждому уникальному пользователю вашего сайта.

    Идентификатор пользователя обычно назначается только зарегистрированным пользователям.

    Разница № 4

    Client ID состоит из уникального случайного числа и первой отметки времени (то есть времени первого посещения). Например: 124562358.46738999.

    ID пользователя состоит из буквенно-цифровых символов. Он не включает первую метку времени. Например: df45346424

    Получить электронную книгу (50 страниц)

    Получите БЕСПЛАТНУЮ электронную книгу (50+ страниц)

    Разница № 5

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

    User ID может существовать на разных устройствах и в браузерах. Благодаря этому атрибуту для измерения на разных устройствах можно использовать идентификатор пользователя.

    Разница № 6

    Client ID не может точно определить количество уникальных пользователей, поскольку уникальный пользователь может быть подсчитан несколько раз, когда он / она переключает устройства / браузеры.

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

    Разница № 7

    Использование идентификатора клиента создает проблемы с атрибуцией, поскольку он существует только на устройстве / браузере, на котором он был настроен. Таким образом, вы не можете приписать вовлеченность пользователей, распределенную по нескольким устройствам и сеансам, одному пользователю в своих отчетах GA.

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

    Разница № 8

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

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

    Статьи по теме:

    Часто задаваемые вопросы о том, что такое идентификатор клиента Google Analytics и чем он отличается от идентификатора пользователя?

    W

    Что такое идентификатор клиента Google Analytics?

    Идентификатор клиента представляет собой уникальный браузер / устройство и создается и назначается файлом cookie Universal Analytics _ga.Идентификатор клиента присваивается каждому уникальному пользователю вашего сайта.

    Как мне найти идентификаторы клиентов?

    Идентификаторы клиентов можно найти в отчете «User Explorer» (в разделе «Audience») в представлении отчетов GA.

    Идентификатор клиента и идентификатор пользователя - одно и то же?

    В контексте Google Analytics «Идентификатор клиента» и «Идентификатор пользователя» - это не одно и то же.

    Client ID представляет собой уникальный браузер / устройство и присваивается файлом cookie Universal Analytics _ga каждому уникальному пользователю вашего веб-сайта.

    User ID представляет собой уникального пользователя, создается и назначается такими людьми, как я и вы, и обычно назначается только зарегистрированным пользователям.

    Настройка OAuth с Zoho

    Вы должны зарегистрировать свое приложение в Zoho API Console, чтобы получить свой Client ID и Client Secret .

    • Идентификатор клиента - это уникальный идентификатор, который вы получаете при регистрации приложения в Zoho.
    • Client Secret - это уникальный ключ, сгенерированный при регистрации вашего приложения в Zoho.Это должно быть конфиденциально.
    • URI авторизованного перенаправления - это конечная точка URI для клиентских приложений, на которую Zoho Accounts должен перенаправить пользовательский агент с токеном доступа после авторизации клиента.
    • Тип клиента - это тип разрабатываемого вами приложения. Тип клиента включает клиентские приложения, серверные приложения, мобильные приложения, приложения без браузера и самостоятельного клиента.

    Примечание : Код авторизации действителен только в течение двух минут и может быть использован только один раз.

    Чтобы зарегистрировать свое приложение

    1. Перейдите в Zoho API Console и щелкните НАЧАТЬ.
    2. Наведите курсор на тип клиента вашего приложения и нажмите СОЗДАТЬ СЕЙЧАС.
    3. Введите имя клиента , URL-адрес домашней страницы и URI авторизованного перенаправления . Если вы выбираете клиентские приложения, вам необходимо ввести URI домена JavaScript .
    4. Щелкните СОЗДАТЬ .

    Self Client

    Если ваше приложение не имеет домена или URL-адреса перенаправления, вы можете выбрать Self Client, чтобы сгенерировать код авторизации.Код авторизации используется для создания токена доступа и токена обновления.

    Для создания собственного клиента:

    1. Перейдите в консоль Zoho API и щелкните НАЧАТЬ.
    2. Наведите указатель мыши на Self Client и нажмите СОЗДАТЬ СЕЙЧАС , затем нажмите ОК.
    3. Вы получите учетные данные клиента, такие как Client ID и Client Secret.
    4. Вы можете сгенерировать код авторизации, заполнив действительные данные области и установив продолжительность в поле Сгенерировать код .

    Настройка клиента приложения пула пользователей

    Приложение - это объект в пуле пользователей, у которого есть разрешение на вызов без аутентификации. API операции (операции, не прошедшие проверку подлинности пользователя). Примеры включают операции к регистрироваться, входить в систему и обрабатывать забытые пароли.Чтобы вызвать эти операции API, вы нужно приложение идентификатор клиента и необязательный секрет клиента. Вы несете ответственность за обеспечение безопасности любого приложения. идентификаторы клиентов или секреты, чтобы только авторизованные клиентские приложения могли вызывать эти неаутентифицированные операции.

    Вы можете создать несколько приложений для пула пользователей.Обычно приложение соответствует Платформа приложения. Например, вы можете создать приложение для серверного приложения и отличающийся Приложение для Android. У каждого приложения есть собственный идентификатор клиента приложения.

    При создании приложения вы можете дополнительно выбрать создание секрета для этого приложения. Если secret создается для приложения, секрет должен быть предоставлен для использования приложения.На основе браузера приложения, написанные на JavaScript, могут не нуждаться в приложении с секретом.

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

    Для создания приложения-клиента (консоли)

    1. На панели мониторинга пула пользователей выберите Создать пул пользователей .

    2. Введите имя пула .

    3. Выбрать Просмотреть значения по умолчанию .

    4. Выберите Добавить клиент приложения .

    5. Выберите Добавить клиент приложения .

    6. Введите имя клиента приложения .

    7. Укажите Срок действия токена обновления для приложения . По умолчанию значение 30. Вы можете изменить его на любое значение от 1 часа до 10 лет.

    8. Укажите Срок действия токена доступа приложения .По умолчанию значение - 1 час. Вы можете изменить его на любое значение от 5 минут до 24 часов.

    9. Укажите срок действия токена ID приложения . По умолчанию значение - 1 час.Вы можете изменить его на любое значение от 5 минут до 24 часов.

      Если вы используете размещенный пользовательский интерфейс и устанавливаете токены менее чем за час, конечный пользователь сможет получать новые токены на основе своего файла cookie сеанса, который в настоящее время установлен на один час.

    10. По умолчанию пользовательские пулы создают секрет клиента для вашего приложения. Если ты этого не хочешь к произошло, очистить Сгенерировать секрет клиента .

    11. Если ваше серверное приложение требует учетных данных разработчика (с использованием подписи версии 4) и не использует Безопасный удаленный пароль (SRP) аутентификация выберите Включить аутентификацию имени пользователя и пароля для API администратора для аутентификации (ALLOW_ADMIN_USER_PASSWORD_AUTH) для включения аутентификации на стороне сервера.Для дополнительную информацию см. в разделе Аутентификация администратора. поток.

    12. Менее Предотвратить ошибки существования пользователя , выберите Legacy или Включено .Для получения дополнительной информации см. Управление ошибочным ответом.

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

      1. Выберите Установить права на чтение и запись атрибутов .

      2. Для установки разрешений на чтение и запись выполните одно из следующих действий:

        • Выберите одну или несколько областей.Каждая область представляет собой набор стандартных атрибутов. Для большего информацию см. перечень стандартных Области применения OIDC.

        • Выберите отдельные стандартные или настраиваемые атрибуты.

      Вы не можете удалить обязательные атрибуты из разрешений на запись в любом приложении.

    14. Выберите Создать клиент приложения .

    15. Если вы хотите создать другое приложение, выберите Добавить приложение .

    16. После того, как вы создали все нужные приложения, выберите Вернуться в пул. подробности , обновите все остальные поля, а затем выберите Создать бассейн .

    Для создания и обновления клиентов приложений в пользовательском пуле (API, AWS CLI)

    Выполните одно из следующих действий:

    .

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *