Kick API OAuth 2.1 + PKCE — руководство по интеграции

24 апреля, 2026

Обновлено 24 апреля, 2026

Публичный API Kick развернул flow OAuth 2.1 + PKCE в конце 2025 года, заменив старые недокументированные эндпоинты. Новый поток стандартно-совместимый и документированный, но отличается от Twitch Helix в нескольких нюансах. Этот гайд проходит полный жизненный цикл — от регистрации приложения до ротации refresh-токена — с разбором ошибок и выбором scope'ов из практики интеграции Kick в reseller-бэкенд Streamrise.

Почему PKCE обязателен на Kick

PKCE (RFC 7636) обязателен на Kick OAuth 2.1 для любого типа клиента — публичных SPA, нативных мобильных приложений и конфиденциальных серверных клиентов. Authorization server Kick отклоняет любой запрос без параметра code_challenge, даже если клиент посылает secret. Это соответствует OAuth 2.1 спецификации 2024 года, которая сделала PKCE единым стандартом для authorization code flow.

Регистрация приложения

Откройте Kick Developer Portal на kick.com/developer и создайте приложение. Укажите имя, redirect URIs (точное совпадение), описание, категорию. На выходе получите client_id (публичный) и client_secret (серверный, для конфиденциальных клиентов).

Redirect URI сверяется строковым сравнением — trailing slash, регистр, поддомены имеют значение. Это самая частая ошибка первой интеграции.

PKCE-пара

Сгенерируйте code_verifier (43-128 символов, высокой энтропии) + code_challenge (SHA-256 от verifier, base64url без padding). Храните verifier на сервере до обмена токена. Используйте code_challenge_method=S256 (Kick отклоняет plain).

Authorization request

Редиректьте пользователя на https://id.kick.com/oauth/authorize с параметрами response_type=code, client_id, redirect_uri, scope, state, code_challenge, code_challenge_method=S256. На ответе проверяйте state для защиты от CSRF.

Обмен code на токены

POST https://id.kick.com/oauth/token с grant_type=authorization_code, code, redirect_uri, client_id, client_secret (если есть), code_verifier. Ответ — JSON с access_token (~1 час), refresh_token (~90 дней), token_type=Bearer, expires_in, scope.

Ротация refresh-токена

Kick ротирует refresh_token на каждом обмене — старый немедленно инвалидируется. Параллельные запросы на refresh нужно сериализовать через mutex, иначе один из них получит invalid_grant.

Scopes

channel:read — чтение метаданных канала
channel:write — обновление категории, title, тегов
chat:read — подписка на сообщения через WebSocket
chat:write — отправка сообщений
stream:read — метаданные live-стрима
user:read — профиль пользователя
follows:read — список фолловеров
subscriptions:read — подписчики (нужен Affiliate)
webhooks:manage — управление webhook-подписками

Rate limits

Per-client_id: 600 запросов/мин. Per-access_token: 180/мин. 429 возвращает Retry-After в секундах — соблюдайте строго. Для высоких нагрузок используйте webhooks вместо polling.

Частые ошибки

invalid_grant — code_verifier не совпадает, code уже использован, или redirect_uri не совпадает
invalid_client — неверный client_id/secret
invalid_request — отсутствует обязательный параметр
invalid_scope — запрошен несуществующий scope
access_denied — пользователь отклонил consent
expired_token — access_token истёк, нужен refresh

Отличия от Twitch Helix OAuth

PKCE обязателен на Kick, опционален на Twitch
Kick ротирует refresh_token, Twitch — нет
Имена scopes различаются
Kick не выдаёт ID-токены (OAuth 2.0 без OIDC)
Webhooks используют разные схемы верификации

Регистрация

Kick API OAuth 2.1 PKCE интеграция