Авторизация в Postman: API-ключи, Bearer-токены и OAuth 2.0

Где настраивается авторизация

У каждого запроса, папки и коллекции в Postman есть вкладка Authorization. Выбранный тип авторизации Postman сам превращает в нужный заголовок или параметр запроса.

Главное правило: настраивайте авторизацию на уровне коллекции. У новых запросов по умолчанию стоит Inherit auth from parent — они берут настройки у папки или коллекции. Если токен поменяется, его обновят в одном месте, а не в каждом запросе.

Если конкретному запросу авторизация не нужна, например эндпоинту логина, выберите для него No Auth.

API Key

Простейший вариант: статический ключ, который сервис выдаёт в личном кабинете.

• Key — имя заголовка или параметра из документации API, например X-API-Key;
• Value — сам ключ, лучше через переменную: {{api_key}};
• Add to — Header или Query Params.

Предпочитайте заголовок: ключ в URL попадает в историю, логи серверов и прокси.

Bearer Token

Используется, когда API выдаёт токен доступа, чаще всего после логина. Postman добавляет заголовок:

Authorization: Bearer <token>

В поле Token укажите переменную {{access_token}}. Токен можно сохранить автоматически: в запросе логина на вкладке Scripts (раздел post-response, в старых версиях Tests) добавьте:

const data = pm.response.json();
pm.environment.set("access_token", data.access_token);

Теперь после логина все запросы коллекции получат свежий токен.

OAuth 2.0

Для OAuth 2.0 Postman умеет сам получать токен. В разделе Configure New Token выберите Grant Type:

Основные поля: Auth URL, Access Token URL, Client ID, Client Secret, Scope и Callback URL. Для потоков через браузер включите Authorize using browser и добавьте в настройках OAuth-приложения на стороне провайдера тот callback URL, который показывает Postman.

Нажмите Get New Access Token, войдите и нажмите Use Token. В новых версиях Postman есть автоматическое обновление токена, если сервер выдаёт refresh token. Проверьте эту настройку в своей версии.

Автообновление токена pre-request скриптом

Если API выдаёт короткоживущие токены, а встроенного обновления нет, добавьте pre-request скрипт на уровне коллекции. Он выполняется перед каждым запросом и получает новый токен, только когда старый истёк:

const expiresAt = Number(pm.environment.get("token_expires_at") || 0);

if (Date.now() > expiresAt) {
  pm.sendRequest({
    url: pm.environment.get("token_url"),
    method: "POST",
    header: { "Content-Type": "application/x-www-form-urlencoded" },
    body: {
      mode: "urlencoded",
      urlencoded: [
        { key: "grant_type", value: "client_credentials" },
        { key: "client_id", value: pm.environment.get("client_id") },
        { key: "client_secret", value: pm.environment.get("client_secret") }
      ]
    }
  }, (err, res) => {
    if (err) { console.error(err); return; }
    const data = res.json();
    pm.environment.set("access_token", data.access_token);
    pm.environment.set("token_expires_at", Date.now() + (data.expires_in - 60) * 1000);
  });
}

На коллекции выберите Bearer Token со значением {{access_token}}. Запас в 60 секунд нужен, чтобы токен не истёк прямо во время запроса. Если провайдер не возвращает expires_in, обновляйте токен по ответу 401.

Как не светить секреты

Общий воркспейс видят все участники, поэтому:

• Храните секреты в переменных окружения, а не в запросах. У переменной есть начальное значение (initial), которое синхронизируется с командой, и текущее (current), которое остаётся на вашем компьютере. Секрет кладите только в current.
• Отмечайте переменные как secret — значение будет скрыто в интерфейсе.
• Используйте Postman Vault, если он доступен: секреты хранятся локально и подставляются как {{vault:имя}}.
• Не экспортируйте коллекции и окружения с реальными токенами, особенно в репозиторий.
• Разделяйте окружения: dev, staging и production с разными ключами, а production-ключи выдавайте как можно меньшему числу людей.
• Если ключ всё же попал в общий доступ, отзовите его у провайдера, а не просто удалите из Postman.