04 oauth2 postman

Многие API требуют не только URL и метод, но и авторизацию: сервер должен понимать, кто обращается и есть ли у клиента право на запрос. Один из самых распространённых стандартов для этого — OAuth 2.0. В этом файле вы узнаете, что такое OAuth 2.0, какие бывают сценарии получения токена, и научитесь настраивать авторизацию в Postman на примере GitHub и типового Client Credentials.

---

1. Зачем нужен OAuth 2.0

Без авторизации API не может понять:

• кто делает запрос (приложение, пользователь);

• имеет ли клиент право на этот ресурс.

Раньше часто передавали логин и пароль в каждом запросе — это небезопасно и неудобно. OAuth 2.0 решает задачу так: клиент сначала получает токен доступа (access token) у сервера авторизации, а затем отправляет только этот токен в запросах к API. Пароль пользователя (если он участвует в сценарии) серверу приложения не передаётся.

В Postman вы настраиваете получение токена один раз (вкладка Authorization), а все запросы в коллекции или к конкретному запросу автоматически отправляются с заголовком Authorization: Bearer <token>.

---

2. Роли и понятия

В OAuth 2.0 участвуют:

• Resource Owner (владелец ресурса) — чаще всего пользователь, чьи данные защищены (например, аккаунт GitHub).

• Client (клиент) — приложение, которое хочет получить доступ к данным (ваше приложение или в нашем случае Postman).

• Authorization Server (сервер авторизации) — выдаёт токены после проверки прав. Может быть частью того же сервиса, что и API (как у GitHub).

• Resource Server (сервер ресурсов) — сам API, который отдаёт данные и проверяет токен (например, api.github.com).

Основные сущности:

• Access Token — строка, которую клиент подставляет в запросы к API. Сервер ресурсов проверяет её и решает, отдавать ли данные. Обычно токен ограничен по времени жизни.

• Refresh Token — выдаётся вместе с access token (не всегда). Используется для получения нового access token без повторного ввода пароля или прохождения авторизации в браузере.

• Client ID и Client Secret — пара идентификаторов приложения, выданная при регистрации у провайдера (GitHub, Google, ваша компания). Secret хранится в тайне и используется при обмене кода на токен или при получении токена по Client Credentials.

В Postman вы указываете Client ID и Client Secret (или другие параметры в зависимости от типа выдачи) и нажимаете Get New Access Token — Postman получает токен и подставляет его в запросы.

---

3. Типы выдачи токена (Grant Types)

Способ, которым клиент получает access token, называется Grant Type. В Postman доступны основные варианты.

Grant Type	Когда используется	В Postman
Authorization Code	Веб-приложения: пользователь логинится в браузере, сервер отдаёт код, клиент обменивает код на токен.	Нужны Auth URL, Token URL, Client ID, Client Secret, Callback URL. Есть кнопка «Authorize using browser».
Authorization Code (With PKCE)	То же, но без Client Secret (мобильные и SPA).	Дополнительно: Code Verifier, Code Challenge Method.
Client Credentials	Сервер-к-серверу: приложение получает токен по своим Client ID и Secret, без участия пользователя.	Нужны Access Token URL, Client ID, Client Secret. Браузер не нужен.
Password	Устаревший вариант: логин и пароль пользователя передаются клиенту, клиент отправляет их на Token URL. Не рекомендуется для сторонних сервисов.	Token URL, Username, Password, при необходимости Client ID/Secret.
Implicit	Редко: токен возвращается в redirect без отдельного обмена. Считается менее безопасным.	Auth URL, Client ID, Callback URL.

В практике чаще всего встречаются Authorization Code (доступ от имени пользователя) и Client Credentials (доступ от имени приложения/сервиса). Ниже разберём оба в Postman.

---

4. Где настраивать OAuth 2.0 в Postman

1. Откройте запрос или коллекцию (чтобы токен применялся ко всем запросам в ней).

2. Перейдите на вкладку Authorization.

3. В поле Type выберите OAuth 2.0.

4. В блоке Configure New Token заполните поля в зависимости от выбранного Grant Type (см. выше).

5. Нажмите Get New Access Token, при необходимости пройдите авторизацию в браузере.

6. В диалоге выберите Use Token — токен подставится в заголовок запроса.

Токен можно привязать к запросу или к коллекции. Если к коллекции — все запросы внутри неё по умолчанию используют этот способ авторизации.

Callback URL: при использовании Authorization Code провайдер после входа пользователя перенаправляет его по этому адресу. Для авторизации через браузер в Postman укажите:

https://oauth.pstmn.io/v1/browser-callback

Этот URL нужно зарегистрировать в настройках OAuth-приложения у провайдера (GitHub, Google и т.д.) в качестве «Authorization callback URL».

---

5. Практика: Authorization Code с GitHub

Здесь мы получим токен от имени пользователя GitHub и сделаем запрос к API GitHub. Регистрация приложения у GitHub бесплатная.

1

Шаг 1: Создать OAuth App в GitHub

1. Войдите в GitHub, откройте Settings → Developer settings → OAuth Apps → New OAuth App.

2. Заполните:

   • Application name: например, Postman — учёба.

   • Homepage URL: можно указать https://www.postman.com или любой валидный URL.

   • Authorization callback URL: обязательно укажите https://oauth.pstmn.io/v1/browser-callback

3. Нажмите Register application.

4. На странице приложения скопируйте Client ID. Нажмите Generate a new client secret и скопируйте Client Secret (он показывается один раз).

2

Шаг 2: Настроить OAuth 2.0 в Postman

1. Создайте новый запрос (или откройте существующий).

2. Authorization → Type: OAuth 2.0.

3. В Configure New Token укажите:

   • Grant Type: Authorization Code.

   • Callback URL: https://oauth.pstmn.io/v1/browser-callback

   • Auth URL: https://github.com/login/oauth/authorize

   • Access Token URL: https://github.com/login/oauth/access_token

   • Client ID: ваш Client ID из GitHub.

   • Client Secret: ваш Client Secret из GitHub.

   • Scope (при необходимости): например, user или repo — через пробел несколько значений. Для простого запроса к /user достаточно user.

4. Включите опцию Authorize using browser (чтобы логин проходил в браузере).

5. Нажмите Get New Access Token.

Откроется браузер с страницей GitHub «Authorize application». Подтвердите доступ. После редиректа Postman получит код и обменяет его на токен. В диалоге нажмите Use Token.

3

Шаг 3: Запрос к API с токеном

В том же запросе установите:

• Метод: GET

• URL: https://api.github.com/user

Не меняя тип авторизации (OAuth 2.0), нажмите Send. В заголовках уйдёт Authorization: Bearer <ваш_токен>. В ответе придёт JSON с данными вашего аккаунта GitHub.

Практика: создайте второй запрос в той же коллекции с OAuth 2.0 на уровне коллекции — GET https://api.github.com/user/repos. Убедитесь, что запрос выполняется без ручной подстановки токена.

---

6. Практика: Client Credentials

В сценарии Client Credentials токен запрашивает само приложение: передаются только Client ID и Client Secret, без входа пользователя в браузере. Так часто работают внутренние или партнёрские API компании: сервис получает токен и ходит в API от своего имени.

1

Как это выглядит в Postman — шаг 1

1. Authorization → Type: OAuth 2.0.

2

Как это выглядит в Postman — шаг 2

1. Grant Type: Client Credentials.

3

Как это выглядит в Postman — шаг 3

1. Заполните:

   • Access Token URL — адрес, на который Postman отправит POST с grant_type=client_credentials и учётными данными клиента (обычно в заголовке Basic Auth или в теле). Его указывает документация API.

   • Client ID — идентификатор приложения.

   • Client Secret — секрет приложения.

4

Как это выглядит в Postman — шаг 4

1. Client Authentication: чаще всего Send as Basic Auth header или Send client credentials in body — как требует ваш API.

2. Нажмите Get New Access Token. Браузер не открывается: Postman сам отправляет запрос на Access Token URL и получает токен из ответа.

Конкретные значения (URL, имена параметров, способ передачи client_id/secret) всегда берут из документации вашего API. У учебного или корпоративного API может быть раздел «OAuth 2.0» или «Authentication» с примерами.

Если у вас пока нет такого API — запомните, что для Client Credentials нужны только Access Token URL, Client ID и Client Secret, и что в Postman для этого не нужен браузер. Когда перейдёте к API вашей компании, заполните эти поля по инструкции и снова нажмите Get New Access Token.

---

7. Использование и обновление токена

• Где виден токен: после «Use Token» он подставляется в запрос. Проверить можно во вкладке Headers (должен быть заголовок Authorization) или в Authorization → выпадающий список токенов.

• Несколько токенов: Postman может хранить несколько полученных токенов. В Authorization в выпадающем списке выберите нужный или нажмите Manage Tokens для просмотра и удаления.

• Обновление (Refresh): если провайдер вернул refresh_token, Postman может автоматически обновлять access token перед истечением срока. Включено опцией Auto-refresh access token. Ручное обновление — кнопка Refresh рядом с токеном.

• Срок действия: у многих провайдеров access token живёт ограниченное время (минуты или часы). После истечения нужно снова нажать Get New Access Token (или положиться на авто-обновление, если есть refresh token).

Удаление токена в Postman не отзывает его на сервере: отзыв делается только на стороне провайдера (например, в настройках GitHub приложения или через API отзыва).

---

8. Что дальше

Вы научились:

• понимать, зачем нужен OAuth 2.0 и что такое access token, refresh token, Client ID/Secret;

• различать основные Grant Types (Authorization Code, Client Credentials);

• настраивать OAuth 2.0 в Postman и получать токен (на примере GitHub);

• делать запросы к API с автоматической подстановкой Bearer-токена.

Дальше в методичке:

• JWT — что это такое, структура токена, использование в API и в Postman (следующий файл);

• работа с API вашей компании (если авторизация через OAuth 2.0 — те же шаги в Postman, другие URL и параметры из документации);

• вызов тех же endpoint’ов через curl и из кода с передачей токена в заголовке.

Рекомендуется сохранить коллекцию с запросом к GitHub, затем перейти к JWT.