Привет всем!
В середине августа планирую провести мощнейший вебинар 🤔 по токенам (авторизация, аутентификация) с уклоном на практику.
Чтобы подготовиться к нему и быть в курсе, ожидайте серию тестов по этой теме — они будут публиковаться на этом канале @protestinginfo до начала вебинара.
Анонс с деталями представлю в начале августа.
Вебинар приурочен к старту новых потоков по тестированию бэкенда и подготовке к собеседованиям.
💻На практике мы разберём различные способы авторизации на разных сервисах — от базовой аутентификации до OAuth 2.0. 💻Также, возможно, затрону тему применения сертификатов при отправке запросов, которые активно используются у меня на работе в финтехе.

Изучаем и закрепляем знания перед тестами

Authorization в Postman
▪️Наследование авторизации (Inherit auth from parent), что пригодится при группировке запросов в коллекции и папки для комплексного тестирования нескольких конечных точек одного веб-сервиса с разными HTTP-запросами, чтобы повторно использовать одни учетные данные вместо ввода этих параметров каждый раз при отправке запроса. По умолчанию запросы внутри коллекции или папки наследуют аутентификацию от родителя...
▪️Отсутствие авторизации (No auth), что не предполагает добавления учетных данных к запросу;
▪️Ключ API (API key) – в заголовок или в параметры HTTP-запроса добавляется пара ключ-значение. Чтобы использовать это для тестирования, предварительно нужно получить ключ разработчика API на стороне тестируемого сервера.
▪️Tокен на предъявителя (Bearer token) – это веб-маркер JSON (JWT, JSON Web Token), который представляет собой текстовую строку, включенную в заголовок запроса, надо предварительно получить токен разработчика API от тестируемого сервера.
▪️ JWT-носитель (JWT bearer), что предполагает генерацию носителя JWT прямо в Postman с использованием криптографических алгоритмов с SHA (HMAC, RSASSA-PKCS1-v1_5, ECDSA, RSASSA-PSS), секрета, закрытого ключа и полезной нагрузки для генерируемого JWT-токена в формате JSON.
▪️Базовая аутентификация (Basic auth) — отправка подтвержденного имени пользователя и пароля вместе с HTTP-запросом. Эти учетные данные добавляются в заголовок HTTP-запроса Authorization в кодировке Base 64. Это не самый безопасный способ, т.к. перехваченные данные легко раскодировать.
▪️Дайджест аутентификации (Digest auth), когда клиент отправляет первый запрос к API, а сервер отвечает несколькими деталями, включая одноразовый номер, значение области действия (realm) и HTTP-ответ со статусом 401. На это клиент снова отправляет серверу зашифрованный массив данных, включая имя пользователя и пароль, вместе с данными, полученными от сервера в первом запросе...(читать далее)
▪️Аутентификация Hawk (Hawk authentication) позволяет использовать частичную криптографическую проверку, задав Hawk Auth ID, Hawk Auth Key и алгоритм хеширования для создания кода аутентификации сообщения (MAC).
▪️Подпись AWS (AWS Signature) для запросов к веб-сервисам Amazon. AWS использует для аутентификации специальную схему HTTP, основанную на ключе HMAC (код аутентификации хэш-сообщения) с ключом доступа и секретом.
▪️NTLM-аутентификация (Windows Challenge/Response) — поток аутентификации для операционной системы Windows и автономных систем с указанием домена или хоста.
▪️Akamai EdgeGrid от провайдера веб-услуг Akamai, что включает учетные данные (токен доступа, токен клиента и секрет клиента), полученные при регистрации клиентского приложения в Akamai.
▪️OAuth 1.0 – аутентификация через стороннего провайдера (например, войти через VK, Google, Github и пр.), которая позволяет клиентским приложениям получать доступ к данным, предоставляемым внешним API, не раскрывая имя пользователя и пароль. Протокол OAuth 1.0 иногда называют двусторонним (аутентификация только между клиентом и сервером) . Чтобы запросить пользовательские данные с помощью стороннего сервиса, клиентское приложение запрашивает маркер доступа, используя учетные данные, такие как ключ и секрет...(читать далее)
▪️OAuth 2.0 является развитием предыдущего вида и предполагает получение токена доступа к API, а затем его использование для проверки подлинности запросов. Обычно доступ к данным с помощью OAuth 2.0 отличается у разных провайдеров API, но включает несколько прямых и обратных запросов между клиентским приложением, пользователем и API...(читать далее)
▪️ASAP (Atlassian) - Протокол аутентификации Atlassian S2S (ASAP ) — это токен-носитель JSON Web Token (JWT), который сервер API может использовать для аутентификации запросов от клиента

источник

На вебинаре я планирую разобрать часто используемые в работе: API Key, Basic Auth, Bearer Token, JWT (JSON Web Token), OAuth 2.0 и еще авторизация через куки, используя заголовок Cookie c значением sessionId