Портал за програмисти

Това ръководство обхваща 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.