Портал розробників

Цей посібник описує 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.