Аутентификация API

Три способа аутентификации в API MeerPartners: вход людей через MeerID OIDC, JWT Bearer для кабинета и HMAC по API-ключу для серверных интеграций. Когда какой использовать.

В MeerPartners три способа аутентификации — каждый под свою задачу. Люди входят через MeerID, браузерный кабинет ходит в API по JWT, а серверные интеграции (postback, SSO) подписывают запросы HMAC по секрету API-ключа.

Какой способ когда

MeerID OIDC — вход людей

Вход в MeerPartners — только через MeerID, единый OIDC SSO экосистемы Meer. Своей регистрации, паролей и OTP у платформы нет. Человек логинится в MeerID, платформа получает подтверждённую личность и обменивает её на локальную пару JWT.

Это публичный эндпоинт первой сессии: браузерный SDK MeerID отдаёт либо code + PKCE (popup/redirect), либо подписанный idToken + nonce (FedCM), а платформа возвращает access_token / refresh_token.

{
  "access_token": "eyJ...",
  "refresh_token": "eyJ...",
  "expires_in": 900,
  "user": {
    "user_id": 42,
    "email": "a@b.io",
    "display_name": "Neo",
    "is_affiliate": false,
    "affiliate_id": null,
    "memberships": []
  }
}

Этим занимается портал MeerPartners — в свою интеграцию этот флоу встраивать не нужно. Если вам нужно авторизовать своих пользователей внутри партнёрки без MeerID, используйте token-exchange, а не OIDC. Как входят люди — см. Регистрация и вход.

JWT Bearer — запросы кабинета

После входа портал работает с API ядра по локальному JWT. Эндпоинты кабинетов (/api/v1/aff/*, /api/v1/merchant/*, /api/v1/auth/me) принимают токен в стандартном заголовке:

Authorization: Bearer <access_token>

Refresh-токены ротируются: при POST /api/v1/auth/refresh старый токен «съедается» и выдаётся новая пара. Повторное использование уже использованного refresh вне короткого grace-окна → TOKEN_REVOKED (401).

API-ключ + HMAC — серверные интеграции

Для S2S-вызовов (сервер вашего бизнеса → платформа) JWT не используется — запрос подписывается HMAC-SHA256 по секрету API-ключа. Так подписываются:

• Постбэк конверсий — POST /api/v1/postback (нужен scope postback);
• Token-exchange / SSO — POST /api/v1/auth/token-exchange (нужен scope sso).

Каждый запрос несёт четыре заголовка и подпись строки запроса:

X-Api-Key-Id: <key_id>
X-Tenant-Id: <tenant_id>        # опционально; если задан — должен совпасть с tenant ключа
X-Timestamp: 1717200000          # epoch-секунды, окно ±300 с
X-Signature: <hex(HMAC_SHA256(secret, signing_string))>

signing_string собирается так:

{METHOD}\n{PATH}\n{X-Timestamp}\n{SHA256_hex(raw_body)}

Тело входит в подпись как хэш — это защищает целостность: сумму или поля заказа нельзя поменять после подписания. Платформа сверяет подпись constant-time и проверяет свежесть X-Timestamp (анти-replay).

Полный алгоритм с примером вычисления, а также скоупы, ротация и отзыв ключей — на следующей странице.

Что дальше