Gigma

Сервис авторизации

Клиент входит по номеру телефона: пароля нет, отдельной регистрации нет, учётная запись создаётся при первом входе. Для продукта это значит, что хранить пароли, делать восстановление и подтверждать почту не нужно.

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

Зачем он нужен

  • Не строить вход самому. Пароли, восстановление, защита от перебора и рассылка кодов — это уже работает, вам остаётся экран с телефоном.
  • Один клиент во всех каналах. Сайт, приложение и miniapp узнают одного и того же человека, а не заводят три учётные записи.
  • Личное закрыто по умолчанию. Заказы, подписки и профиль отдаются только по токену клиента: витрине не нужно решать, кому что показывать.
  • Доступ можно отозвать. Видно, с каких устройств вошли, и лишние сессии закрываются.

Вход за два запроса

Клиент называет телефон и получает код:

POST /api/counterparty/send_password HTTP/1.1
Host: api.gigma.ru
Token: <application_token>
Content-Type: application/json

{ "phone": "79999999990" }

Код меняется на токен:

POST /api/counterparty/login HTTP/1.1
Host: api.gigma.ru
Token: <application_token>
Content-Type: application/json

{ "phone": "79999999990", "password": "1111", "device": "storefront-web" }

В ответе приходит профиль клиента и access_token.value — это Bearer, который вы сохраняете на устройстве. Контракты обоих методов и коды ошибок — на странице входа клиента.

Как выглядит запрос после входа

GET /api/counterparty/orders HTTP/1.1
Host: api.gigma.ru
Token: <application_token>
Authorization: Bearer <counterparty_token>

Два заголовка отвечают на разные вопросы: Token — чьё это приложение, Authorization — какой клиент. Публичное (каталог, страницы, тарифы) открывается первым, личное (заказы, профиль, подписки) — только вторым.

Другие способы подтвердить клиента

  • Звонок вместо кода — клиент звонит на выданный номер, фронтенд опрашивает статус и забирает токен. Подходит там, где вводить код неудобно.
  • Miniapp Max или Telegram — личность подтверждает сам мессенджер, кода нет вообще.

Оба способа заканчиваются тем же Bearer и описаны там же — вход клиента.

Что делать с токеном дальше

  • Продлевать, пока клиент работает — heartbeat.
  • Показывать и отзывать устройства — сессии клиента.
  • Проверять на своём сервере, если он есть. Токен приходит от браузера, поэтому перед выдачей закрытых данных ваш backend проверяет его через introspect — интеграция с backend.

Вход сотрудника и агента

Команда и программы входят иначе: сотрудник получает свой Bearer, агент — Agent Token, и оба живут только на сервере. Контракты — вход сотрудника и получение доступа агентом.

Чего нельзя делать

App Token лежит в браузере и виден любому: он не подтверждает личность и не заменяет вход. Не отдавайте по нему личные данные и не считайте его секретом. Bearer сотрудника во фронтенд не передаётся вообще — даже в админку, которая работает в браузере.

Дальше

© 2026 Gigma