Портал разработчиков

В этом руководстве описаны OAuth-авторизация и токены, которые использует Application. Кто такие Partner, Application (Client) и User, см. Partner, приложение и пользователь.

Поток авторизации

Когда Application должна действовать от имени User, User должен предоставить доступ через OAuth:

sequenceDiagram
    actor User
    participant App as Application
    participant OLX as OLX
    App->>User: 1. Показывает ссылку аутентификации OLX
(/oauth/authorize)
    User->>OLX: 2. Открывает ссылку в браузере, входит
и принимает Application
    OLX->>User: 3. Перенаправление браузера с authorization_code
    User->>App: 4. Браузер переходит на redirect_uri
с authorization_code
    App->>OLX: 5. Обмен authorization_code на токены
(grant_type: authorization_code)
    OLX->>App: access_token, refresh_token
    Note over App: Хранит токены только для этого User.
User их не видит.

Операции

После авторизации User работает только с Application. Application вызывает OLX API с сохранённым access_token. User никогда не отправляет и не получает этот токен:

sequenceDiagram
    actor User
    participant App as Application
    participant API as OLX API
    User->>App: 1. Инициирует действие
(без OLX access_token)
    Note right of User: напр. опубликовать это предложение на OLX
    App->>API: 2. API-запрос с access_token
напр. POST /adverts
    Note over App,API: access_token используется здесь
(только Application ↔ OLX API)
Токен остаётся в Application
User не отправляет и не получает его
    API->>App: 3. Ответ API
успех / ошибка
    App->>User: 4. Показывает результат User
(без OLX access_token)

Токены, которые использует Application

В процессе авторизации участвуют следующие элементы:

Контекст User — токен в контексте конкретного User

Используется, когда Application действует от имени User (продавец / lister).

• authorization_code — одноразовый код, который Application получает после того, как User предоставил доступ к учётной записи OLX. Application обменивает этот код на access_token и refresh_token.
• access_token — токен, который Application отправляет с API-запросами от имени этого User. Имеет ограниченный срок (см. expires_in в ответе токена). Когда он истекает, Application использует refresh_token для нового access_token. С access_token User Application может публиковать объявления, читать статусы, получать сообщения и выполнять другие действия в scope пользователя. Токен для User John Doe нельзя использовать для User Jane Humbug — запасы каждого User остаются отдельными.
• refresh_token — токен, используемый в контексте User для получения нового access_token после истечения предыдущего. Живёт дольше access token. Его можно использовать до истечения или аннулирования. Поток refresh может вернуть новый refresh_token — сохраните его и используйте самый новый. Если refresh_token истечёт или станет недействительным, User должен снова пройти авторизацию для нового authorization_code и новых access_token и refresh_token.

Контекст Client — токен в контексте Application

Получается с grant type client_credentials. Эти токены не имеют контекста User. Они используются для операций, не требующих данных User — например категории, локации и другие общие данные между Users.

• access_token — токен, который Application отправляет с API-запросами в контексте Application (Client). Также имеет ограниченный срок; по истечении Application запрашивает новый с client_id / client_secret и grant_type: client_credentials. В этом потоке нет refresh_token. Этот токен не может действовать от имени User — только получает доступ к общим ресурсам.
• client_id / client_secret — учётные данные Application из Developer Portal. Вместе с grant_type: client_credentials используются для получения токена в контексте Client. (client_credentials — название grant type, а не сам secret.)

Подробности запросов, endpoints и scopes — в разделе Authentication документации API.

Чтобы зарегистрироваться как Partner и создать Application, следуйте Получение доступа к API.