Применяли ли вы когда либо JWT? Скорее всего, да, если хоть раз выполняли проверку работоспособности программного обеспечения, которое содержит в своей структуре логику аутентификации и авторизации.
Термин JWT можно произносить как «джот» и расшифровать как JSON Web Token. Все JWT разрабатываются фирмой Aut0, которая поставила своей целью давать программным продуктам возможность оперировать методом определения, есть ли у пользователей корректные права для доступа на определенный веб-ресурс.
Чем полезны JWT? С их помощью можно облегчить работу приложения по верификации авторизационных данных пользователя, не передавая при этом логин, пароль или куки-файлы.
Можно перехватывать разнообразные запросы, но JWT вообще не содержит персональной информации и полностью зашифрован, а значит, его перехват не будет полезным.
Далее поговорим о том, как разрабатываются JWT и как правильно их стоит тестировать.
Структура JWT
Итак, любой JSON Web Token состоит из трех базовых частей, которые структурно выстроены из определенной последовательности цифр и букв, разделенных между собой точками.
Один из наиболее эффективных методов изучить и усвоить особенности JWT — постоянно практиковаться с официальным JWT-отладчиком, который можно найти по следующей ссылке: http://jwt.io/
Заголовок любого JWT состоит из специального алгоритма, который используют для целей шифрования JWT, а также вид токена.
Заголовок JWT
В самих данных содержится группа утверждений пользователя.
Есть сразу три вида утверждений:
- Зарегистрированные утверждения — классические утверждения, которые были предопределенные программным кодом JWT утверждения (iss — создатель заявления; iat — дата выпуска токена в unix-переменной; exp — срок годности утверждения токена; aud — получатель токена; sub — информация для пользователя);
- Публичные утверждения — второй вид традиционных утверждений, которые добавляются в реестр JWT. Например, имя, почта и временная зона действия токена;
- Частные утверждения — третья группа утверждений, определяющихся создателем приложения, которые считаются специфическими для одной локальной группы использования. Например, фирма может назначать оригинальный userId для всех своих пользователей, и это будет включено в тело утверждения.
Пример из отладчика:
{
«Sub»: «1234567890»
«Name»: «Name Surname»
«iat»: 1516239022
}
Здесь object — 1234567890, имя пользователя, у которого есть персональный доступ к данному объекту — Name Surname, а сам токен был создан в 1516239022, согласно Юникс-времени.
Если начинающим тестировщикам такая раскладка времени не очень ясна, можно воспользоваться услугами специального конвертера, который поможет все детально расшифровать.
Ссылка: https://www.epochconverter.com/
Теперь разберем подпись.
Она берется из первых двух секций и кодирует их в Base64. Потом к этим закодированным секциям можно добавить оригинальный секретный ключ — очень длинную строку символов и цифр. И в завершении, подпись зашифровывает все вместе на основе алгоритма HMAC SHA256.
Любой JWT имеет следующую структуру: закодированный заголовок, части закодированных данных и закодированная подпись пользователя. Для того, чтобы отчетливо различать все три секции, отладчик JWT может подсвечивать их разными цветами.
Если вы, как QA специалист, часто встречаете JWT внутри проверяемого программного обеспечения, вы можете попробовать взять какой-то токен и разобрать его структуру через JWT-отладчик. Расшифрованная информация сможет подсказать вам всю специфику функционирования программного обеспечения, которое тестируются на данный момент.
Но если у вас на проекте нет JWT, вы запросто можете создать его самостоятельно. Для этого вам потребуется вставлять информацию в секцию Payload отладчика и анализировать, как именно редактируется зашифрованный JWT :
{
«sub» : «user»
«userName» : «test»
«iss» : 1516239022
«exp» : 1586606340
}
Во время декодирования настоящего JWT подпись не будет расшифровываться потому, что есть секрет! Но учитывая тот факт, что первые две части JWT закодированы, а не зашифрованы — их запросто можно раскодировать.
Использование и нюансы тестов JWT
Применять JWT можно очень по-разному, но наиболее распространенный вариант — выполнять передачу его в теле API-запроса посредством bearer-токена. К примеру, в Postman это отображается следующим образом:
Применение JWT в Postman
После того, как мы разобрали структуру и предназначение JWT, можно проанализировать, как их корректно тестировать:
- Попытайтесь самостоятельно отправить запрос без JWT, дабы проверить, что данные смогут вернуться;
- Отредактируйте или удалите один символ из JWT и проверьте, что данные не вернуться во время использования такого токена внутри запроса;
- Выполните декодирование корректного JWT внутри отладчика, отредактируйте данные в нем, потом протестируйте, сможет ли он функционировать в запросе;
- Проверьте, когда заканчивается срок действия JWT, и попытайтесь отправить запрос с истекшим токеном, дабы протестировать, что отправленные данные не будут возвращены;
- Разверните новый JWT, срок действия которого начнется в будущем, и протестируйте, что данные не будут возвращены;
- Попробуйте раскодировать JWT и проверить, что в его структуре не сохраняются персональные данные пользователя, к примеру, номер и срок действия банковской карты.
Оставить комментарий