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

Обзор

Целью потока аутентификации является идентификация и аутентификация пользователя для платежного интегратора (интегратора).

Аутентификация является входными данными для других методов. В частности, для associateAccount и capture . Это означает, что доказательство аутентификации используется в качестве входных данных (параметра) для этих двух методов.

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

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

Как работает поток

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

1. Перенаправление аутентификации
2. SMS-MT OTP-аутентификация

Перенаправление аутентификации

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

1. Google перенаправляет пользователя на веб-сайт интегратора или в приложение Android, где он может пройти аутентификацию.
2. Для аутентификации requestId аутентификации (из AuthenticationRequest ) используется в качестве доказательства аутентификации.
3. В результате получается подписанный ответ, называемый AuthenticationResponse .
4. После этого приложение или веб-сайт перенаправляет пользователя обратно в Google.

Примечание. В автономном режиме подписанный ответ (шаг 3) и gspResult определяют, прошла ли аутентификация успешно.

Аутентификация с перенаправлением использует метод HTTP GET с параметрами, закодированными в URL-адресе веб-приложения. Он использует Android Intent для аутентификации приложения Android. Дополнительные сведения о кодировании см. в разделе Веб-аутентификация , а о параметрах намерений Android — в разделе Android Authentication .

Результатом работы каждого из этих механизмов аутентификации является подписанный ответ, называемый AuthenticationResponse . Это намерение должно включать зашифрованный ответ аутентификации Google Standard Payments ( gspAuthenticationResponse ), чтобы сообщить об успешной аутентификации. При использовании в автономном режиме gspResult и подпись используются для определения успешной аутентификации.

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

На следующей диаграмме последовательности показано взаимодействие между браузером пользователя, Google и веб-приложением интегратора:

Процесс аутентификации Redirect-Web

Вот список объектов и то, что они представляют:

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

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

1. Пользовательский интерфейс Google создает URL-адрес аутентификации, который отправляется на сервер Google (серверная часть). Это то, что запускает процесс аутентификации.
2. Сервер Google создает запрос на аутентификацию ( AuthenticationRequest ).
3. Запрос аутентификации отправлен в пользовательский интерфейс Google.
4. Пользователь получает запрос на аутентификацию своего идентификатора у интегратора.
5. Пользователь отвечает, что хочет пройти аутентификацию, и это сообщение отправляется на веб-сайт интегратора.
6. Веб-сайт Платежного интегратора запрашивает подтверждение личности пользователя.
7. Пользователь предоставляет подтверждение своей личности, которое отправляется на сайт Интегратора платежей.
8. Интегратор создает ответ ( authenticationResponse ) на предоставленные доказательства (с authenticationResponse закодированным в сообщении).
9. Этот URL-адрес ответа отправляется пользователю.
10. URL-адрес ответа немедленно отправляется пользователем в пользовательский интерфейс Google.
11. Пользовательский интерфейс Google отправляет ответ на сервер Google.
12. Сервер Google интерпретирует ответ как проверенный.

Следующая диаграмма последовательности показывает взаимодействие между телефоном пользователя, Google и Android-приложением интегратора:

Перенаправление – процесс аутентификации приложения Android

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

Вот объекты и что они представляют:

• Пользователь : это человек, который хочет добавить способ оплаты в свою учетную запись Google.
• Пользовательский интерфейс Google : в данном случае это интерфейс приложения, в котором клиент начинает настраивать способ оплаты.
• Сервер Google : внутренний сервер Google, который выполняет проверку аутентификации, а также другие задачи аутентификации.
• Payment Integrator APK : приложение интегратора, в котором пользователь имеет доступ к своей учетной записи интегратора.
• Сервер платежного интегратора : внутренний сервер интегратора, на котором хранится информация пользователя.

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

1. Пользовательский интерфейс Google создает вызов аутентификации, который отправляется на сервер Google (серверная часть).
2. Сервер Google создает запрос на аутентификацию ( AuthenticationRequest ).
3. Сервер Google отправляет APK вызова в пользовательский интерфейс (приложение) Google, запрашивая аутентификацию.
4. Пользовательский интерфейс Google отправляет информацию о пользователе в APK-файл Payment Integrator ( AUTHENTICATE_V1(authReq) ).
5. APK-файл Payment Integrator отправляет запрос ( authReq ) на сервер Payment Integrator.
6. Сервер Payment Integrator отправляет запрос обратно в APK Payment Integrator.
7. APK-файл Payment Integrator отправляет запрос обратно пользователю.
8. Пользователь предоставляет подтверждение своей личности, которое отправляется в APK-файл Payment Integrator.
9. Это подтверждение затем отправляется на сервер Payment Integrator.
10. Сервер создает подписанный authenticationResponse .
11. Ответ на аутентификацию успешен, и в APK-файл Payment Integrator отправляется сообщение authResp .
12. Сообщение об успешном выполнении ( authResp ) отправляется из APK Payment Integrator в пользовательский интерфейс Google.
13. Пользовательский интерфейс Google отправляет ответ на сервер Google.
14. Сервер Google интерпретирует успешный ответ.

SMS-MT OTP-аутентификация

Другой метод аутентификации — служба коротких сообщений, мобильный терминал, одноразовый пароль (SMS-MT OTP). Этот механизм использует номер телефона пользователя для отправки ему одноразового пароля для аутентификации. Google просит интегратора отправить OTP на номер телефона пользователя, и после того, как пользователь получит его, а затем введет его в интерфейс Google, пользователь будет проверен.

Это включает в себя следующие шаги:

1. Пользовательский интерфейс (UI) Google предлагает пользователю ввести номер телефона, который уже зарегистрирован у интегратора.
2. Пользователь вводит номер телефона в пользовательском интерфейсе Google.
3. Google запускает интегратор (вызывает метод sendOtp ) для отправки пользователю одноразового пароля (OTP).
4. Пользователь получает SMS-сообщение с OTP.
5. Затем пользователь вводит OTP (используемый в качестве входных данных для capture , associateAccount и verifyOtp ), который он получил, в интерфейс Google, аутентифицируя пользователя. Это подтверждение аутентификации.

В автономном режиме для проверки значения OTP будет вызываться только verifyOtp .

На следующей диаграмме последовательности показано взаимодействие между телефоном пользователя, Google и интегратором при отправке OTP:

Процесс аутентификации телефона (отправка OTP)

Примечание. На приведенной выше диаграмме не показано использование OTP в качестве входных данных для другого вызова. Однако это будет использоваться в качестве входных данных для различных вызовов, таких verifyOtp и associateAccount .

Вот список объектов на диаграмме и то, что они представляют:

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

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

1. Пользовательский интерфейс Google (телефон или веб-сайт) запрашивает у пользователя номер телефона.
2. Пользователь вводит свой номер телефона в интерфейс Google.
3. Пользовательский интерфейс Google отправляет номер ( sendChallenge(phoneNum) ) на сервер Google.
4. Сервер Google отправляет запрос на сервер Интегратора платежей ( SendOtp(phoneNum) ) для отправки одноразового пароля.
5. Сервер Payment Integrator отправляет пользователю одноразовый пароль (OTP).
6. Сервер платежного интегратора отвечает на запрос Google в №5, сигнализируя об успешной отправке OTP.
7. Пользователь вводит этот OTP в пользовательский интерфейс Google (телефон или веб-сайт).
8. Пользовательский интерфейс Google отправляет OTP на сервер Google, где он в конечном итоге отправляется интегратору платежей для проверки. Это проверяет личность пользователя и аутентифицирует пользователя.

Аутентификация и повторная аутентификация

Есть два момента времени, когда может произойти аутентификация:

1. Первоначальная аутентификация — используется для идентификации и аутентификации пользователя. Первоначальная аутентификация используется в качестве входных данных для метода associateAccount .
2. Повторная аутентификация — используется во всех других контекстах, например, в автономном режиме или в качестве входных данных для capture .

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

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

Для повторной аутентификации SMS-MT OTP Google сохраняет номер телефона, указанный во время исходного вызова sendOtp , как фиксированный номер. Это нельзя изменить, опять же в целях безопасности.

Вот пример процесса, когда Google решает бросить вызов (повторную аутентификацию) перед совершением покупки:

Поток повторной аутентификации

Список объектов и то, что они представляют, следующий:

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

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

1. Пользователь решает приобрести товар или услугу.
2. Запрос отправляется из пользовательского интерфейса Google на сервер Google.
3. Сервер Google отправляет обратно запрос аутентификации ( authenticationRequest ) в пользовательский интерфейс Google.
4. Пользовательский интерфейс Google отправляет запрос в пользовательский интерфейс Интегратора платежей для аутентификации ( associationId , authenticationRequest ) пользователя.
5. Пользовательский интерфейс Интегратора платежей ищет пользователя, чтобы подтвердить его личность ( LookupIdentity ( associationId )).
6. Пользовательский интерфейс Payment Integrator запрашивает у пользователя учетные данные в его пользовательском интерфейсе (на веб-сайте или в приложении интегратора).
7. Ответ аутентификации отправляется на сервер Payment Integrator.
8. Подписанный ответ аутентификации ( authenticationResponse ) отправляется обратно в пользовательский интерфейс Payment Integrator.
9. Ответ аутентификации ( authenticationResponse ) отправляется из пользовательского интерфейса Payment Integrator в пользовательский интерфейс Google.
10. Пользовательский интерфейс Google отправляет ответ с информацией о покупке на сервер Google.
11. Сервер Google отправляет сообщение capture (для поиска доступных средств) на сервер Интегратора платежей ( authenticationRequestId , GPT, сумма).
12. Сервер платежного интегратора отправляет сообщение об успехе обратно на сервер Google.
13. Сервер Google отправляет сообщение об успехе в пользовательский интерфейс Google.
14. Пользовательский интерфейс Google доставляет товары покупателю (или уведомляет его о том, что они скоро будут доставлены).

СМС-МО аутентификация

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

Вот список объектов на диаграмме и то, что они представляют:

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

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

1. Пользователь выбирает токенизированный инструмент для добавления.
2. Пользовательский интерфейс Google вызывает сервер Google, чтобы инициировать вызов SMS-MO.
3. Сервер Google возвращает инструкции SMS, состоящие из пункта назначения и тела, содержащего идентификатор запроса аутентификации.
4. Пользовательский интерфейс Google отправляет SMS платежному интегратору.
5. Сервер платежного интегратора вызывает конечную точку аутентификацииResultNotification на сервере Google с идентификатором запроса аутентификации.
6. Идентификатор запроса аутентификации проверяется сервером Google, который отвечает УСПЕХОМ.
7. Пользовательский интерфейс Google обращается к серверу Google, чтобы получить результат попытки аутентификации.
8. Ответ сервера Google: УСПЕШНО.

Имитация SMS-MO-аутентификации

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

Вот список объектов на диаграмме и то, что они представляют:

• Тестер : это человек, который инициирует диагностический тест ассоциации SMS-MO.
• Пользовательский интерфейс Google : пользовательский интерфейс Google, в котором тестер запускает и отслеживает состояние диагностического теста SMS-MO.
• Сервер Google : внутренний сервер Google, который генерирует инструкции SMS с идентификатором запроса аутентификации (ARID), отправляет имитированное SMS-сообщение и получает результат аутентификации от интегратора.
• Сервер платежного интегратора : внутренний сервер интегратора, который получает SMS-сообщение с имитацией аутентификации и возвращает идентификатор запроса аутентификации в Google.

Шаги в этом потоке:

1. Тестер начинает диагностический тест SMS-MO, предоставляя идентификатор тестового абонента (SID), который будет использоваться для теста. Этот SID будет включен в вызов simulateSms к интегратору платежей.
2. Пользовательский интерфейс Google вызывает сервер Google, чтобы инициировать вызов SMS-MO.
3. Сервер Google возвращает инструкции SMS, состоящие из пункта назначения и тела, содержащего идентификатор запроса аутентификации. В целях этого теста место назначения будет переопределено HTTPS-соединением с изолированной программной средой Интегратора платежей.
4. Пользовательский интерфейс Google вызывает сервер Google для отправки имитированного SMS-сообщения.
5. Вызов simulateSms выполняется с сервера Google на сервер платежного интегратора. Идентификатор запроса аутентификации и идентификатор подписчика (как указано на шаге 1) включаются в вызов API.
6. Сервер Платежного Интегратора отвечает ПОДТВЕРЖДЕНО.
7. Сервер Google отвечает УСПЕХОМ на пользовательский интерфейс Google.
8. Сервер платежного интегратора вызывает конечную точку аутентификацииResultNotification на сервере Google с идентификатором запроса аутентификации.
9. Сервер Google отвечает УСПЕХОМ.
10. Пользовательский интерфейс Google обращается к серверу Google, чтобы получить результат попытки аутентификации.
11. Сервер Google отвечает ЗАВЕРШЕНО.
12. Пользовательский интерфейс Google вызывает сервер Google для выполнения попытки ассоциации.
13. Вызов associateAccount выполняется с сервера Google на сервер Интегратора платежей.
14. Сервер платежного интегратора отвечает УСПЕШНО.
15. Сервер Google отвечает УСПЕХОМ.
16. Пользовательский интерфейс Google обновляется, показывая тестеру, что диагностический тест SMS-MO завершился успешно.

Лучшие практики и другие соображения

Выбор платформ

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