Авторизация игроков через De&Play: как проверять покупку игры и получать данные пользователя

Если вы публикуете игру на De&Play, у вас почти наверняка возникает два вопроса:

1. Как убедиться, что человек, который запустил вашу игру, действительно её купил — а не скачал взломанную копию у знакомого или с торрента?

2. Как получить данные об игроке (ник, аватар) прямо в игре — например, чтобы показать их в онлайн-профиле, в списке лидеров или в чате?

Для обеих задач на De&Play есть единый механизм — Game Auth API. Он позволяет:

• проверить, куплена ли игра пользователем, который её запустил (лицензионная проверка);

• получить базовые данные пользователя — nickname, username, avatar;

• один раз авторизовать игрока и дальше «узнавать» его автоматически при каждом следующем запуске, без повторного похода в браузер.

В этой статье мы разберём протокол целиком — так, чтобы вы могли реализовать его сами на любом движке (Unity, Unreal, Godot, свой лаунчер и т.д.), а в конце покажем готовый SDK для Unity, который делает всё то же самое из коробки.

---

⚠️ Важно понимать: клиентская авторизация — это защита от «случайного» распространения и базовая проверка лицензии, а не абсолютная защита от взлома. Ни один клиентский SDK не может гарантировать 100% защиту скомпилированной игры от модификации. Для по-настоящему критичных вещей (античит, серверная логика, экономика) стоит дублировать проверки на своём игровом сервере, а не полагаться только на клиентский токен.

---

1. Общая логика: два сценария

Вся система построена вокруг двух сценариев:

🔵 Первый запуск (у пользователя ещё нет сохранённого токена устройства)

1. Игра создаёт auth-сессию на бэкенде De&Play.

2. Открывается браузер со страницей входа на de-play.ru.

3. Пользователь логинится (если ещё не залогинен) и подтверждает вход в игру.

4. Игра, пока пользователь авторизуется в браузере, опрашивает (polling) статус сессии.

5. Как только статус меняется на approved, игра получает одноразовый JWT-токен и обменивает его на постоянный device token — с проверкой покупки игры.

6. Device token сохраняется локально (например, в PlayerPrefs для Unity) для будущих запусков.

🟢 Повторный запуск (device token уже сохранён)

1. Игра отправляет сохранённый device token на эндпоинт silent-авторизации.

2. Бэкенд проверяет, что сессия устройства всё ещё активна и (если игра платная) что покупка всё ещё существует.

3. Если всё в порядке — пользователь сразу входит в игру, без браузера и подтверждений.

4. Если токен невалиден (например, сессию отозвали или сбросили) — игра просто откатывается к сценарию первого запуска.

Ниже — разбор каждого шага с точки зрения реальных запросов к API.

2. Подготовка: clientId

Прежде чем стучаться в API, у вашей игры должен быть clientId — идентификатор игрового клиента, привязанный к конкретной игре (или к её черновику на этапе модерации). Он выдаётся в личном кабинете разработчика на De&Play при создании игры и является публичным — его зашивают прямо в билд игры, ничего секретного в нём нет.

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

3. Создание auth-сессии

Когда пользователь нажимает «Войти» (или это происходит автоматически при первом запуске), игра создаёт сессию авторизации.

Запрос:

POST https://api.de-play.ru/game/auth/session
Content-Type: application/json

{
  "clientId": "ваш_client_id",
  "deviceId": "уникальный_id_устройства"
}

deviceId генерируется на стороне игры и должен быть стабильным между запусками одного и того же устройства/установки. Если у платформы есть свой стабильный идентификатор устройства — используйте его, если нет — сгенерируйте случайный UUID при первом запуске и сохраните локально.

Ответ:

{
  "sessionId": "a1b2c3d4...",
  "authUrl": "https://de-play.ru/game/auth/a1b2c3d4...?deviceId=..."
}

authUrl — это готовая ссылка на страницу De&Play, где пользователь логинится и подтверждает вход именно в вашу игру. Игре нужно просто открыть эту ссылку в браузере по умолчанию (в Unity — Application.OpenURL). Дальше подтверждение входа полностью происходит на стороне сайта — самой игре ничего реализовывать для этого шага не нужно.

Сессия живёт 10 минут — если пользователь за это время не подтвердит вход, она сгорит и нужно будет создавать новую.

4. Ожидание подтверждения (polling)

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

Запрос:

GET https://api.de-play.ru/game/auth/session/{sessionId}

Возможные ответы:

Пока пользователь ещё не подтвердил вход:

{
  "status": "pending"
}

После подтверждения:

{
  "status": "approved",
  "token": "eyJhbGciOi..."
}

Рекомендуемые параметры опроса — как в нашем собственном Unity SDK: интервал 2 секунды, общий таймаут ожидания 120 секунд. Если за это время подтверждения не пришло — считайте сессию истёкшей и предложите пользователю попробовать снова.

Как только вы получили status: "approved" — токен из ответа одноразовый и живёт всего 5 минут, поэтому следующий шаг (verify) нужно выполнять сразу же, без задержек.

5. Верификация токена и проверка покупки

Это ключевой шаг — именно здесь бэкенд проверяет, что игра действительно куплена, и отдаёт запрошенные данные пользователя.

Запрос:

POST https://api.de-play.ru/game/auth/verify
Content-Type: application/json

{
  "token": "eyJhbGciOi...",
  "clientId": "ваш_client_id",
  "deviceId": "уникальный_id_устройства",
  "nickname": true,
  "username": false,
  "avatar": false
}

Поля nickname, username, avatar — необязательные булевы флаги: вы сами решаете, какие данные пользователя хотите получить. Если игра платная и пользователь её не покупал — сервер вернёт ошибку, и дальше в игру попасть будет нельзя.

Успешный ответ:

{
  "purchased": true,
  "purchaseDate": "2026-01-15T10:00:00.000Z",
  "deviceId": "уникальный_id_устройства",
  "user": {
    "nickname": "SomeNick"
  },
  "deviceToken": "8f21a9c4..."
}

deviceToken из этого ответа нужно сохранить локально (у себя в игре) — именно он используется дальше для тихой (silent) авторизации при следующих запусках, без похода в браузер.

Если игра бесплатная (или доступ выдан по другим правилам — например, это черновик, доступный автору для тестирования) — поле purchased тоже будет true, но без обязательной проверки покупки.

Важный нюанс про идентификацию пользователя

API возвращает nickname, username и avatar, но не возвращает отдельный неизменяемый числовой/UUID-идентификатор пользователя. При этом username в De&Play уникален, но пользователь может менять его в любой момент на сайте.

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

6. Тихая (silent) авторизация при следующих запусках

При каждом следующем запуске игры, если у вас уже есть сохранённый deviceToken, не нужно снова открывать браузер — можно попробовать авторизоваться «в тихую».

Запрос:

POST https://api.de-play.ru/game/auth/silent
Content-Type: application/json

{
  "clientId": "ваш_client_id",
  "deviceId": "уникальный_id_устройства",
  "deviceToken": "8f21a9c4..."
}

Успешный ответ:

{
  "purchased": true,
  "purchaseDate": "2026-01-15T10:00:00.000Z",
  "user": {
    "nickname": "SomeNick"
  }
}

Обратите внимание: в отличие от /verify, эндпоинт /silent всегда возвращает только nickname (если он вообще есть) — выбрать username/avatar здесь нельзя, набор данных фиксированный.

Если сервер вернул ошибку (401/400) — это значит, что сессия устройства протухла, была отозвана, либо покупка игры больше не подтверждается (например, был оформлен возврат). В этом случае просто удалите локально сохранённый deviceToken и запустите обычный сценарий первого запуска (создание сессии → браузер → verify).

7. Ограничение частоты запросов (rate limiting)

Эндпоинты /verify и /silent защищены лимитом: не более 20 запросов за 5 минут на комбинацию clientId + IP. При превышении сервер вернёт ошибку с кодом 504 и сообщением о том, что запросов слишком много.

На практике это никак не мешает нормальной работе — обычная игра делает один запрос на /silent при запуске и один на /verify при первом логине. Лимит рассчитан на защиту от подбора токенов и от случайных циклов переподключения — так что если вы реализуете повторные попытки при ошибке, закладывайте между ними паузу (backoff), а не мгновенный ретрай в цикле.

8. Готовый SDK для Unity

Если у вас Unity-проект — всё описанное выше уже реализовано в официальном De&Play Unity SDK, и вручную писать запросы не придётся.

SDK умеет:

• показывать экран авторизации при запуске игры;

• автоматически делать тихий вход, если устройство уже авторизовано;

• открывать браузер и вести polling при первом входе;

• сохранять токен между запусками;

• отдавать данные пользователя через простой API:

string nickname = DePlayAuthSystem.Instance.UserData.nickname;
string avatar   = DePlayAuthSystem.Instance.UserData.avatar;
bool isLoggedIn = DePlayAuthSystem.Instance.IsAuthenticated;

Установка

Добавьте в manifest.json вашего Unity-проекта:

{
  "dependencies": {
    "com.deplay.sdk": "https://github.com/mizam0/deplay-unity-sdk.git"
  }
}

Либо скачайте SDK архивом и распакуйте папку DePlaySDK в Assets/.

Дальше нужно:

1. Добавить сцену авторизации из SDK первой в Build Settings.

2. Создать конфиг через Right Click → Create → De&Play → Auth Config и указать в нём Client Id (тот самый, из личного кабинета разработчика).

3. Убедиться, что на сцене есть объект DePlayAuthSystem со ссылкой на созданный конфиг.

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

Полная документация по установке, настройке и использованию SDK — в README репозитория: 👉 https://github.com/mizam0/deplay-unity-sdk

Итог

Авторизация через De&Play решает сразу две задачи: защищает вашу игру от бесконтрольного распространения нелицензионных копий и даёт готовый способ получать данные игрока без необходимости писать собственный backend для аккаунтов. Протокол одинаковый для любого движка — если Unity SDK вам не подходит, вы всегда можете реализовать те же четыре запроса самостоятельно на любом стеке.

Если у вас возникнут вопросы по интеграции — пишите в поддержку De&Play, поможем разобраться.