Авторизация настраивается во вкладке Auth редактора запроса и превращается в обычный заголовок или query-параметр перед отправкой. В селекторе Authorization Type девять пунктов: Inherit, None, Basic Auth, Bearer Token, API Key, OAuth 2.0, JWT Bearer, Digest, AWS Signature. На корешке вкладки виден бейдж с выбранным типом — (Bearer), (OAuth2), (AWS), — так что заглядывать внутрь ради проверки не нужно.
Типы авторизации#
Inherit. Своих полей у запроса нет, настройки берутся у родительской коллекции — как именно, разобрано ниже.
None. Ничего не добавляется. Заголовок Authorization, выставленный вручную во вкладке Headers, при этом остаётся — Tetiva его не трогает.
Basic Auth. Поля Username и Password. Отправляется заголовок Authorization: Basic <base64(username:password)>. Кнопка с глазом рядом с паролем показывает введённое значение, если нужно свериться.
Bearer Token. Поля Prefix и Token. Prefix по умолчанию Bearer, и заголовок собирается как Authorization: Bearer <token>. Префикс можно заменить на свой — например Token — или стереть совсем: тогда в заголовок уйдёт только само значение токена, без префикса и пробела. Токен скрыт точками, как пароль Basic, и кнопка с глазом его показывает. Значение из одних ссылок {{variable}} видно всегда. С пустым токеном заголовок Authorization не отправляется вовсе, о чём говорит подсказка под полем, а перевод строки в конце вставленного токена отрезается.
API Key. Поля Key, Value и переключатель Add to. Значение ключа скрыто так же, как токен. Если имя ключа пустое, к запросу ничего не добавляется, и подсказка под Key это объясняет; перевод строки в конце вставленного значения тоже отрезается.
Headerкладёт пару в заголовки запроса как есть.Query Paramsдобавляет параметр в URL: значение кодируется, а одноимённый параметр, если он уже был в строке, перезаписывается.
Для режима Header пять имён запрещены — host, content-length, authorization, connection, transfer-encoding. Попытка отправить запрос с таким ключом завершится ошибкой, а не молчаливой подменой служебного заголовка. Если нужен именно Authorization, выберите Bearer или Basic.
Оставшиеся четыре схемы устроены сложнее, и у каждой своя форма.
OAuth 2.0#
Форма начинается с селектора гранта. Их четыре: Client Credentials, Password Credentials, Authorization Code, Device Code. Набор полей меняется вместе с грантом.
Общие поля: Token URL, Client ID, Client Secret, Client Authentication (Basic header, Request body или None (public client)), Scope, Audience, а ниже — Add token to со значениями Header и Query Params и парное к нему Header Prefix либо Query Parameter. Password Credentials добавляет Username и Password, Authorization Code — Authorization URL и Redirect Port, Device Code — Device Authorization URL.
Кнопка Get token запускает поток, Clear стирает полученный токен, Cancel прерывает ожидание. В Authorization Code приложение открывает браузер само, а рядом появляются Open again и Copy link на случай, если он не открылся. В Device Code ссылку открываете вы — кнопкой Open.
Кнопки «Refresh» в форме нет: истекающий токен обновляется по refresh-токену автоматически, перед отправкой запроса. Если пригодного refresh-токена не осталось, дальше всё зависит от гранта: Client Credentials и Password Credentials получают новый токен сами, а Authorization Code и Device Code просят снова нажать Get token. Текущее состояние написано строкой над кнопками — Valid until 14:05, Valid until Sep 8, 14:05, Valid, Expired, will refresh, Expired или No token.
Authorization Code всегда идёт с PKCE, отдельного переключателя для этого нет. Возврат из браузера ловит локальный слушатель на 127.0.0.1, redirect URI выглядит как http://127.0.0.1:<порт>/callback. Порт задаётся полем Redirect Port с подсказкой Loopback port for the callback; 0 picks a free one.; по умолчанию там 21830. Занятый порт приложение назовёт ошибкой прямо под полем — поставьте 0, и порт выберется сам. Перезагрузка окна ожидание не сбрасывает.
Полученные токены лежат в локальной базе. Между устройствами они не синхронизируются и в экспорт коллекции не попадают. А вот сами учётные данные — другое дело: экспорт в Postman пишет в файл client secret, пароль, секретный ключ AWS и приватный ключ JWT открытым текстом.
JWT Bearer#
Токен подписывается в момент отправки, поэтому хранить и обновлять его не нужно.
Алгоритмов тринадцать: HS256, HS384, HS512, RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, EdDSA; по умолчанию HS256. Для семейства HS форма показывает Secret и Secret Encoding (Plain text или Base64 encoded), для остальных — Private Key.
Дальше идут Payload (claims), Expires In (seconds), JOSE Header и знакомые Add token to с Header Prefix или Query Parameter. По умолчанию токен уходит заголовком с префиксом Bearer, живёт 3600 секунд, а имя query-параметра — token.
Три подсказки в форме стоит прочитать целиком:
iat and exp are added at send time unless the claims set them.— время выпуска и срок вписывать руками не надо;0 signs a token without exp.— так подписывается токен без срока годности;kid, typ, cty, x5t, x5u and jku only — alg comes from the algorithm above.— вJOSE Headerкладут только эти поля,algприложение подставит из селектора.
Digest#
В форме два поля — Username и Password. Выбора алгоритма нет: его диктует сервер, а приложение отвечает тем, что тот попросил. Подсказка под полями говорит ровно это: The algorithm follows the server challenge: MD5, SHA-256 and SHA-512-256 are supported.
Челлендж и повторная отправка проходят внутри одного запроса, поэтому в истории остаётся одна запись — и заголовок Authorization в неё не пишется.
Чего Digest в Tetiva не умеет: вариантов -sess и qop=auth-int. На требование MD5-sess запрос завершится ошибкой server requires MD5-sess, which is not supported. Редиректы для Digest выключены: ответ на челлендж должен уйти на тот же адрес, для которого он посчитан.
AWS Signature V4#
В селекторе схема подписана AWS Signature. Поля: Access Key ID, Secret Access Key, Session Token (подсказка Only for temporary STS credentials.), Region и Service. Обязательны все, кроме Session Token.
В подпись входят заголовок host, все заголовки x-amz-*, content-type и content-md5. X-Amz-Date приложение ставит всегда, X-Amz-Security-Token — если задан session token, X-Amz-Content-Sha256 — для сервисов семейства s3. Редиректы, как и у Digest, выключены.
Переменные в полях авторизации#
Все поля авторизации понимают {{переменные}}: подсветка, автодополнение по {{ и подсказка при наведении работают здесь так же, как в теле запроса. Типичная схема — держать {{token}} в поле Bearer, а само значение обновлять post-скриптом после логина.
Подстановка выполняется уже после pre-скрипта, поэтому токен, записанный скриптом через pm.environment.set, попадает в заголовок в том же прогоне. Идёт она по разобранным полям, а не по их тексту, так что кавычки и обратные слэши в пароле или ключе запрос не портят. Подробнее — в разделах Окружения и переменные и Скрипты.
Наследование от коллекции#
У коллекции есть собственная авторизация: «Открыть коллекцию» → раздел «Авторизация». Пунктов в списке на один меньше, чем у запроса: вместо пары Inherit и None у коллекции верхнего уровня есть No Auth, а у вложенной — Inherit. В обоих случаях своей авторизации коллекция не добавляет.
Вложенная коллекция на Inherit показывает, что получат её запросы: строку Requests in this collection inherit auth from parent collections, под ней схему и коллекцию, от которой она приходит, а для OAuth 2.0 ещё и состояние токена. Если выше никто авторизацию не задал, там написано No parent collection sets auth — requests here go without it unless they set their own. Коллекция верхнего уровня на No Auth пишет Requests here go without auth unless they set their own.
Запрос с типом Inherit не хранит своих полей — он ищет настройки вверх по дереву:
- Берётся коллекция, в которой лежит запрос.
- Если у неё задана своя схема — используется она, поиск закончен.
- Если у неё
Inherit(на верхнем уровне —No Auth), тот же вопрос задаётся её родителю, и так далее до корня. - Ничего не нашлось — запрос уходит без авторизации, а вкладка Auth пишет
No parent collection sets auth — this request goes without it.
Обход ограничен 50 уровнями вложенности. На практике это защита от испорченного дерева, а не рабочий предел: коллекции такой глубины никто не строит.
Сама вкладка Auth при Inherit показывает результат поиска: строку This request inherits authentication from its parent collection, под ней — от кого именно, например OAuth 2.0 configured on collection “Payments”. Имя коллекции кликабельно и открывает её вкладку сразу на разделе «Авторизация». Для унаследованного OAuth 2.0 добавляется срок токена: Valid until 14:05 — manage the token on that collection's Auth tab. Если у унаследованного Bearer пустой токен или у API Key нет имени, ниже появляется янтарная строка, например Its token is empty, so no Authorization header is sent.
Практический вывод простой. Держите общие учётные данные на верхней коллекции сервиса, оставляйте вложенным папкам Inherit — они прозрачны для поиска — и переопределяйте авторизацию только там, где endpoint действительно отличается, например на /auth/login, которому токен не нужен.
Порядок применения#
Перед отправкой HTTP-запроса Tetiva выполняет шаги строго по очереди: подстановка переменных → pre-скрипт → авторизация → автоматический Content-Type. Если в pre-скрипте ошибка, цепочка на нём обрывается и запрос не уходит — см. Скрипты.
Отсюда следствие, которое иногда удивляет: авторизация записывается последней и перезаписывает заголовок, выставленный раньше. Если pre-скрипт положил свой Authorization, а во вкладке Auth выбран Bearer, отправится значение из вкладки Auth. Чтобы скрипт был главным, выберите тип None.
Где авторизация не применяется#
Настройки вкладки Auth действуют для HTTP, GraphQL и рукопожатия WebSocket. Но Digest и AWS Signature — только для HTTP: в GraphQL и WebSocket их нельзя выбрать заново, а если такая схема уже стоит на запросе, она остаётся видимой в селекторе и под ним висит янтарная строка с её именем: Digest is supported for HTTP requests only; this request will fail to send.
У gRPC вкладки Auth нет, и авторизацию коллекции он не берёт, какая бы схема там ни стояла: учётные данные передаются метаданными — например ключом authorization со значением Bearer {{token}}. Значения метаданных тоже поддерживают переменные, а вот наследования метаданных от коллекции нет: общий ключ для всех запросов коллекции ставится её pre-скриптом через pm.request.metadata.set — см. gRPC.
Из известных схем в Tetiva нет NTLM, Hawk и OAuth 1.0. Всё, что подписывается по телу запроса нестандартным способом, по-прежнему собирается pre-скриптом: посчитайте значение, положите его в переменную и подставьте в поле Bearer или API Key.
Где хранятся данные#
Учётные данные лежат в локальной базе SQLite рядом с остальными полями запроса и коллекции, открытым текстом. MCP-инструменты их не отдают: auth_data в ответах заменяется на [redacted], а заодно маскируются значения заголовков и query-параметров с учётными данными — см. MCP-сервер.
Повтор из истории учётные данные тоже не переносит. Кнопка «Повторить» собирает черновик с типом None, из него вырезаются все заголовки с учётными данными (Authorization, Cookie, X-API-Key и подобные) и query-параметры с именами вроде token или api_key, а также те, что добавила авторизация. В записях, сделанных начиная с версии 1.3, вырезается и заголовок, в котором ключ API ушёл под своим именем. Плашка над черновиком предупреждает, что авторизация и заголовки с учётными данными в него не попали. История хранит запрос в том виде, в каком он собран до отправки, а не копию с провода: cookie из jar, заголовок Digest и подпись AWS добавляются позже и в запись не попадают, а у GraphQL-записи остаётся текст запроса до подстановки переменных — см. Просмотр ответа.
Copy as cURL, наоборот, кладёт в команду то, что уже получено, и за токеном в сеть не ходит. Если токена OAuth 2.0 нет, команда уйдёт без Authorization и с предупреждением no cached OAuth 2.0 token: the command carries no Authorization; get a token in the Auth tab first. Digest превращается в --digest -u, AWS Signature — в --aws-sigv4; подробности — в разделе Импорт и экспорт.
Настройка авторизации на уровне папки описана также в разделе Коллекции.