Как проверить jwt токен на валидность

How to validate or verify JWT Signature?

Class org.springframework.security.jwt.JwtHelper has a static method which allows you to parse the JWT token and verify its signature.

answered Apr 15, 2014 at 11:47
Vladimír Schäfer Vladimír Schäfer
15.5k 2 2 gold badges 52 52 silver badges 72 72 bronze badges
thanks a lot.you saved my time.But using this jar it’s not validating token against expiration time
Apr 16, 2014 at 7:32

That’s correct, the library doesn’t interpret any claims contained inside the token (i.e. it doesn’t try to understand what’s the content of the token), this implies that it also doesn’t check any expiration. Also, your question was only about verification of signatures. It is trivial to check the expiration in your own code and is probably preferred, as the claim «exp» can be encoded in different ways (e.g. include or skip milliseconds).

JSON Web Token и Secure Sockets Layer

Для начала разберем небольшую задачу. Она поможет читателю получить представление об основах шифрования.

Представим, что у нас есть сундук с важными документами. Мы хотим отправить его из пункта А в пункт Б, но так, чтобы никто не мог открыть его содержимое по пути следования. На сундук можно повесить замок/замки, отправлять сундук несколько раз, принимать обратно, передавать ключ/ключи через посредника. Посредник может скопировать ключ или даже сам сундук, подобно файлам на компьютере. Как же выстроить цепочку передачи, чтобы посредник не получил доступ к закрытым документам при перевозке?

Прежде чем прочитать правильный ответ, подумайте самостоятельно:

Вариант 1

В пункте А вешаем замок и отправляем в пункт Б.
В пункте Б вешаем еще один замок и отправляем обратно в пункт А.
В пункте А открываем замок который изначально повешали в пункте А и возвращаем в пункт Б.
В пункте Б открываем второй замок, извлекаем содержимое.

Данное решение является верным, но нерентабельным, нужно тратить много времени на перевозку, выполняя двойную работу.

Избегаем лишних «движений»

Вариант 2

Из пункта А отправляем замок без ключа.
В пункте Б у нас есть замок и два комплекта ключей. Один из них положим в сундук и закроем на замок, который получили из пункта А. Затем возвращаем обратно в пункт А.
Получаем сундук в пункте А, открываем замок и достаем ключ.

Готово! Теперь в пунктах А и Б есть одинаковые ключи, и можно обмениваться данными, используя один замок.

По ходу повествования читатель поймет необходимость данного примера. А сейчас немного про шифрование.

Шифрование

Выделяют 2 типа шифрования: симметричное и асимметричное.

Симметричное шифрование — способ шифрования, в котором для шифрования и дешифрования применяется один и тот же криптографический ключ. Проблемой данного способа является передача ключа. Необходимо исключить возможность кражи при передаче.

Асимметричное шифрование — процесс, при котором для шифрования данных используется публичный ключ, а для дешифровки – приватный.

Вспомним «Вариант 2» задачи в начале статьи.

Когда передаем замок без ключа из пункта А в пункт Б, в пункте Б мы получаем замок (публичный ключ) которым можно только зашифровать, то есть закрыть сундук.

При помощи его в пункте Б шифруем свой ключ (положим один из дубликатов ключей в сундук и закроем замком, который получили из пункта А) отправляем обратно в пункт А.

В пункте А откроем сундук ключом (расшифруем данные приватным ключом).

Теперь в пунктах А и Б есть одинаковые ключи, и можно проводить симметричное шифрование, использовать 1 замок и дубликаты ключей с каждой стороны.

Как работает SSL

Когда пользователь заходит на сайт, устанавливается защищенное ssl соединение. Данная операция будет происходить каждый раз при новом заходе на сайт. При запросе браузер проверяет наличие сертификата у сервера. В ответ сервером отправляется публичный ключ с сертификатом. Браузер осуществляет проверку сертификата в центре сертификации. Если с сертификатом все хорошо генерирует сеансовый ключ, необходимый для симметричного шифрования и для обеспечения сервера копией данного ключа в дальнейшем. Когда сеансовый ключ сгенерирован, браузер зашифровывает его публичным ключом, полученным с сервера, затем отправляет обратно. Сервер расшифровывает сообщение приватным ключом и сохраняет сеансовый. Далее обмен данными происходит с помощью симметричного шифрования с использованием HTTPS.

JWT Описание стандарта. Правила хранения токенов. Способы передачи и проверки подлинности. Роль SSL при передаче данных.

JWT (JSON Web Token) — это стандарт, основанный на формате JSON, позволяющий создавать токены доступа, используемые для аутентификации в клиент-серверных приложениях.

JSON Web Token (JWT) — содержит три блока, разделенных точками

token —

header — заголовок,

payload — полезная нагрузка,

signature — подпись.

token = < alg:"HS256", typ:"JWT" >. < iss:"auth.myservice.com", user:"test", role:"admin" >. eae1d799c0f6211da133ad35213

Header — служебная часть токена. Определяет как обрабатывать полученную информацию

typ — тип токена, например JWT;

alg — алгоритм, использованный для генерации подписи.

Payload — полезная нагрузка

Payload — Любые данные о пользователе, для дальнейшей идентификации

Список стандартных данных для payload:

iss (issuer) — определяет приложение, из которого отправляется токен. sub (subject) — определяет тему токена. exp (expiration time) — время жизни токена. iss — (issuer) издатель токена. sub — (subject) "тема", назначение токена. aud — (audience) аудитория, получатели токена. exp — (expire time) срок действия токена. nbf — (not before) срок, до которого токен не действителен. iat — (issued at) время создания токена. jti — (JWT id) идентификатор токена.

Если необходимо ограничить токен по времени, поле exp или iat обязательно. По ним система проверяет актуальность токена.

S9Z8uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY

Signature — сумма header + payload, зашифрованных определенным образом.

header и payload кодируются при помощи алгоритма base64url, затем объединяются

в единую строку с использованием точки («.») и шифруются алгоритмом с использованием секретного ключа.

signature = HMACSHA256(base64UrlEncode(header) + " ." +base64UrlEncode(payload),SECRET_KEY)

Собранный токен

JWT = base64UrlEncode(header) + "." + base64UrlEncode(payload) + "." + signature

Проверка JWT токена на подлинность

Создаем сигнатуру из header и payload

newSignature = HMACSHA256( header + "." + payload, SECRET_KEY)

сравниваем получившиеся сигнатуру с сигнатурой из токена:

if(newSignature === signature)

Аутентификация по JWT

В системах аутентификации, основанных на JWT, после прохождения аутентификации пользователь получает два токена:

Access token — для авторизации и идентификации пользователя.

Refresh token — для обновления access token.

Access token ограничен по времени жизни (например, 10 минут). Refresh token действителен дольше, например, месяц или неделю. Refresh token необходим для обновления access token. При истечении срока refresh token пользователь заново проходит процедуру аутентификации.

После получения токенов при последующих обращениях access токен передается приложению в заголовке запроса от пользователя

Получив токен от пользователя, приложение проверит его подпись и актуальность. Убедившись в действительности и не истекшем сроке жизни токена, приложение авторизует его используя данные из токена. Если на одном из этапов произошла ошибка, приложение вернет ошибку с кодом «401».

При получении ошибки «401» пользователю необходимо обновить access с помощью refresh токена, отправив запрос по api. Например, api/refresh. В ответ получаем новую пару access и refresh токена. После повторно отправляем изначальный запрос.

Где хранить токены

Представим ситуацию: пользователь авторизовался и получил 2 токена:

access — живет 3 мин;

refresh мы сохраняем в cookie пользователя.

access держим в памяти, и при каждом обновлении страницы, выполняем запрос refresh для получения новой пары такенов. Либо есть вариант когда мы записываем access в cookie.

Не стоит хранить access или refresh токен в localstore, это не безопасно.

Устанавливаем заголовки для set-cookie:

sameSite: true, SameSite=strict (для предотвращения CSRF-атак)

secure: true, разрешает обмен только по https (ssl) и предотвращает перехват access токена

Для refresh cookie

httpOnly: true, запрет чтения/записи данных Cookie посредством JavaScript для refresh

path: равный пути, по которому осуществляется получение новой пары access и refresh токенов. Например (api/refresh)

Для отправки access на сервер вижу 2 варианта

1) При каждом запросе пользователя, будь то получение или изменение каких-либо данных, отправляется заголовок

Authorization = `Bearer $`

если в данном варианте токен храним в cookie, а не в памяти, то httpOnly будет равен false, чтобы с помощью js было возможным записать заголовок. рекомендую в данном случае использовать память.

2) Хранить и передавать access токен в cookie с httpOnly = true, тогда нам не придется использовать для этого заголовок (что не является обязательным). httpOnly = true является более безопасным вариантом

Внимание! Не отправляйте refresh токен в cookie на сервер

Https (SSL) вас защитит, так как данные передаются в шифрованном виде, но данный подход не совсем верный, так как при изменении https на http появляется уязвимость. Вдобавок использование двух токенов теряет смысл.

При получении и записи cookie с refresh токеном у нее должен быть указать path равный url, по которому мы обновляем токены ‘api/refresh’. Так мы исключаем отправку refresh токена в других запросах. Это защищает от перехвата обоих токенов и бесконечного обновления access.

Если же мы будем передавать 2 токена и выполнять refresh на сервере при возникновении кражи можно бесконечно выполнять refresh с учетом того что пользователь не будет заходить на сайт. При входе пользователь перелогиниться и получит новую пару. Злоумышленник утратит возможность использовать токены.

Перехват токена

Если злоумышленник получит токен, то сможет декодировать его, используя функцию base64UrlDecode.

Для предотвращения угроз рекомендуется:

использовать защищенное соединение при передаче токенов;
не использовать в токене секретную информацию о пользователе;
для передачи токенов использовать https (ssl);
использовать ограниченное время жизни токенов;
не передавайте access и refresh токены вместе. При хранении токенов в cookie, нужно вырезать рефреш при отправке.

Если у злоумышленника окажется оба токена: refresh и access, он сможет выполнять refresh и обновлять их бесконечно. Наш аccess станет недействительным, и придется сделать logout. В противном случае это сделает приложение. После выполняется login, происходит получение новой пары refresh и access. Злоумышленник больше не сможет использовать токены. Это одно из преимуществ данной технологии.

Подбор ключа

При использовании шифрования алгоритмом HS256 мы используем секретный ключ. Злоумышленник может узнать наш ключ с помощью подбора.

Рекомендации для защиты от атаки подбора ключей:

SECRET_KEY — рекомендуется хранить в env переменных;

Использовать ключ большой длины: большие и малые буквы, цифры и спецсимволы;

Периодическая смена ключа. При такой процедуре пользователю придется заново проходить процедуру аутентификации, но это поможет сделать систему более безопасной.

Главная проблема LocalStorage

Не храните jwt в локальном хранилище, js скрипты на нашем сайте легко могут получить данные из LocalStorage нашего приложения, у локального хранилища нет никаких способов защиты, то есть если мы храним секретные данные в локальном хранилище, информация доступна всем.

Пример инъекции в js

Допустим, у нас на сайте есть скрипт

Скрипт является взломанным и несет в себе вредоносный код, который прочитывает все данные в локальном хранилище и отправляет на сервер для сбора украденной информации. Используя внешние скрипты на сайте, мы всегда рискуем. То же самое касается и установки пакетов через npm или yarn: нет уверенности в их безопасности. Даже сам автор скрипта/плагина может использовать вредоносный код.

Альтернативы локальному хранилищу

Куки

httpOnly — запретит js читать данные из cookie.

SameSite=strict для предотвращения CSRF-атак, а также флаг.

Secure=true — передача только по https

Сессии

Используйте серверную сессию для хранения секретных данных.

Заключение

SSL — стандарт нашего времени. Браузеры запрещают посещение ресурсов без этого протокола.

JSON Web Tokens — популярная технология. При правильном использовании JWT избавляет от ошибки недостаточной авторизации, позволяет быстро распределять информационные потоки между сервисами, с едиными учетными данными и повысить их производительность.

Информационная безопасность
Криптография

Шпаргалки по безопасности: JWT

Многие приложения используют JSON Web Tokens (JWT), чтобы позволить клиенту идентифицировать себя для дальнейшего обмена информацией после аутентификации.

JSON Web Token – это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON.

Эта информация является проверенной и надежной, потому что она имеет цифровую подпись.
JWT могут быть подписаны с использованием секретного (с помощью алгоритма HMAC) или пары открытого / секретного ключей с использованием RSA или ECDSA.

JSON Web Token используется для передачи информации, касающейся личности и характеристик клиента. Этот «контейнер» подписывается сервером, чтобы клиент не вмешивался в него и не мог изменить, например, идентификационные данные или какие-либо характеристики (например, роль с простого пользователя на администратора или изменить логин клиента).

Этот токен создается в случае успешной аутентификации и проверяется сервером перед началом выполнения каждого клиентского запроса. Токен используется приложением в качестве “удостоверения личности” клиента (контейнер со всей информацией о нем). Сервер же имеет возможность проверять действительность и целостность токена безопасным способом. Это позволяет приложению быть stateless (stateless приложение не сохраняет данные клиента, сгенерированные за один сеанс для использования в следующем сеансе с этим клиентом (каждый сеанс выполняется независимо)), а процессу аутентификации независимым от используемых сервисов (в том смысле, что технологии клиента и сервера могут различаться, включая даже транспортный канал, хотя наиболее часто используется HTTP).

Соображения по поводу использования JWT

Даже если токен JWT прост в использовании и позволяет предоставлять сервисы (в основном REST) без сохранения состояния (stateless), такое решение подходит не для всех приложений, потому что оно поставляется с некоторыми оговорками, как, например, вопрос хранения токена.

Если приложение не должно быть полностью stateless, то можно рассмотреть возможность использования традиционной системы сессий, предоставляемой всеми веб-платформами. Однако для stateless приложений JWT – это хороший вариант, если он правильно реализован.

Проблемы и атаки, связанные с JWT

Использование алгоритма хеширования NONE

Подобная атака происходит, когда злоумышленник изменяет токен, а также меняет алгоритм хеширования (поле “alg”), чтобы указать через ключевое слово none, что целостность токена уже проверена. Некоторые библиотеки рассматривали токены, подписанные с помощью алгоритма none, как действительный токен с проверенной подписью, поэтому злоумышленник мог изменить полезную нагрузку (payload) токена, и приложение доверяло бы токену.

Для предотвращения атаки необходимо использовать библиотеку JWT, которая не подвержена данной уязвимости. Также во время проверки валидности токена необходимо явно запросить использование ожидаемого алгоритма.

Пример реализации:

// Ключ HMAC хранится как String в памяти JVM private transient byte[] keyHMAC = . ; . // Создание контекста верификации для запроса к токену // Явно указывается использование HMAC-256 хеш-алгоритма JWTVerifier verifier = JWT.require(Algorithm.HMAC256(keyHMAC)).build(); // Верификация токена DecodedJWT decodedToken = verifier.verify(token);

Перехват токенов

Атака происходит, когда токен был перехвачен или украден злоумышленником и он применяет его для получения доступа к системе, используя идентификационные данные определенного пользователя.

Защита заключается в добавлении «пользовательского контекста» в токен. Пользовательский контекст будет состоять из следующей информации:

Случайная строка, которая генерируется на этапе аутентификации и включена в токен, а также отправлена клиенту в виде более защищенного cookie (флаги: HttpOnly + Secure + SameSite + cookie префиксы).
Хеш на алгоритме SHA256 от случайной строки будет сохранен в токене, чтобы любая проблема XSS не позволила злоумышленнику прочитать значение случайной строки и установить ожидаемый файл cookie.

Если во время проверки токена полученный токен не содержит правильного контекста, он должен быть отклонен.
Пример реализации:

Код для создания токена после успешной аутентификации:

// Ключ HMAC хранится как String в памяти JVM private transient byte[] keyHMAC = . ; // Генератор случайных данных private SecureRandom secureRandom = new SecureRandom(); . // Генерация случайной строки, которая является фингерпринтом пользователя byte[] randomFgp = new byte[50]; secureRandom.nextBytes(randomFgp); String userFingerprint = DatatypeConverter.printHexBinary(randomFgp); // Добавление фингерпринта в cookie String fingerprintCookie = "__Secure-Fgp=" + userFingerprint + "; SameSite=Strict; HttpOnly; Secure"; response.addHeader("Set-Cookie", fingerprintCookie); // SHA256 хеш от фингерпринта для хранения хеша фингерпринта в токене // (вместо открытых данных) чтобы XSS не мог прочитать фингерпринт и // самостоятельно установить нужное значение cookie MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] userFingerprintDigest = digest.digest(userFingerprint.getBytes("utf-8")); String userFingerprintHash = DatatypeConverter.printHexBinary(userFingerprintDigest); // Создание токена с временем валидности 15 минут и контекстом клиента Calendar c = Calendar.getInstance(); Date now = c.getTime(); c.add(Calendar.MINUTE, 15); Date expirationDate = c.getTime(); Map headerClaims = new HashMap<>(); headerClaims.put("typ", "JWT"); String token = JWT.create().withSubject(login) .withExpiresAt(expirationDate) .withIssuer(this.issuerID) .withIssuedAt(now) .withNotBefore(now) .withClaim("userFingerprint", userFingerprintHash) .withHeader(headerClaims) .sign(Algorithm.HMAC256(this.keyHMAC));

Код для проверки валидности токена:

 // Ключ HMAC хранится как String в памяти JVM private transient byte[] keyHMAC = . ; . // Получение фингерпринта пользователя из cookie String userFingerprint = null; if (request.getCookies() != null && request.getCookies().length > 0) < Listcookies = Arrays.stream(request.getCookies()).collect(Collectors.toList()); Optional cookie = cookies.stream().filter(c -> "__Secure-Fgp" .equals(c.getName())).findFirst(); if (cookie.isPresent()) < userFingerprint = cookie.get().getValue(); >> // Вычисление SHA256 хеша от полученного фингерпринта из cookie для // сравнения с хешем фингерпринта в токене MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] userFingerprintDigest = digest.digest(userFingerprint.getBytes("utf-8")); String userFingerprintHash = DatatypeConverter.printHexBinary(userFingerprintDigest); // Создание контекста для верификации токена JWTVerifier verifier = JWT.require(Algorithm.HMAC256(keyHMAC)) .withIssuer(issuerID) .withClaim("userFingerprint", userFingerprintHash) .build(); // Верификация токена DecodedJWT decodedToken = verifier.verify(token);

Явное аннулирование токена пользователем

Поскольку токен становится недействительным только после истечения срока его действия, у пользователя нет встроенной функции, позволяющей явно отменить действие токена. Таким образом, в случае кражи пользователь не может сам отозвать токен и затем заблокировать атакующего.

Одним из способов защиты является внедрение черного списка токенов, который будет пригоден для имитации функции «выход из системы», существующей в традиционной системе сеансов.

В черном списке будет храниться сборник (в кодировке SHA-256 в HEX) токена с датой аннулирования, которая должна превышать срок действия выданного токена.

Когда пользователь хочет «выйти», он вызывает специальную службу, которая добавляет предоставленный токен пользователя в черный список, что приводит к немедленному аннулированию токена для дальнейшего использования в приложении.

Пример реализации:

Хранилище черного списка:
Для централизованного хранения черного списка будет использоваться база данных со следующей структурой:

create table if not exists revoked_token(jwt_token_digest varchar(255) primary key, revokation_date timestamp default now());

Управление аннулированиями токенов:

// Контролирование отката токена (logout). // Используйте БД, чтобы разрешить нескольким экземплярам проверять // отозванный токен и разрешить очистку на уровне централизованной БД. public class TokenRevoker < // Подключение к БД @Resource("jdbc/storeDS") private DataSource storeDS; // Проверка является ли токен отозванным public boolean isTokenRevoked(String jwtInHex) throws Exception < boolean tokenIsPresent = false; if (jwtInHex != null && !jwtInHex.trim().isEmpty()) < // Декодирование токена byte[] cipheredToken = DatatypeConverter.parseHexBinary(jwtInHex); // Вычисление SHA256 от токена MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] cipheredTokenDigest = digest.digest(cipheredToken); String jwtTokenDigestInHex = DatatypeConverter.printHexBinary(cipheredTokenDigest); // Поиск токена в БД try (Connection con = this.storeDS.getConnection()) < String query = "select jwt_token_digest from revoked_token where jwt_token_digest = ?"; try (PreparedStatement pStatement = con.prepareStatement(query)) < pStatement.setString(1, jwtTokenDigestInHex); try (ResultSet rSet = pStatement.executeQuery()) < tokenIsPresent = rSet.next(); >> > > return tokenIsPresent; > // Добавление закодированного в HEX токена в таблица отозванных токенов public void revokeToken(String jwtInHex) throws Exception < if (jwtInHex != null && !jwtInHex.trim().isEmpty()) < // Декодирование токена byte[] cipheredToken = DatatypeConverter.parseHexBinary(jwtInHex); // Вычисление SHA256 от токена MessageDigest digest = MessageDigest.getInstance("SHA-256"); byte[] cipheredTokenDigest = digest.digest(cipheredToken); String jwtTokenDigestInHex = DatatypeConverter.printHexBinary(cipheredTokenDigest); // Проверка на наличие токена уже в БД и занесение в БД в // обратном случае if (!this.isTokenRevoked(jwtInHex)) < try (Connection con = this.storeDS.getConnection()) < String query = "insert into revoked_token(jwt_token_digest) values(?)"; int insertedRecordCount; try (PreparedStatement pStatement = con.prepareStatement(query)) < pStatement.setString(1, jwtTokenDigestInHex); insertedRecordCount = pStatement.executeUpdate(); >if (insertedRecordCount != 1) < throw new IllegalStateException("Number of inserted record is invalid," + " 1 expected but is " + insertedRecordCount); >> > > >

Раскрытие информации о токене

Эта атака происходит, когда злоумышленник получает доступ к токену (или к набору токенов) и извлекает сохраненную в нем информацию (информация о токене JWT кодируется с помощью base64) для получения информации о системе. Информация может быть, например, такой как, роли безопасности, формат входа в систему и т.д.

Способ защиты достаточно очевиден и заключается в шифровании токена. Также важно защитить зашифрованные данные от атак с использованием криптоанализа. Для достижения всех этих целей используется алгоритм AES-GCM, который обеспечивает аутентифицированное шифрование с ассоциированными данными (Authenticated Encryption with Associated Data – AEAD). Примитив AEAD обеспечивает функциональность симметричного аутентифицированного шифрования. Реализации этого примитива защищены от адаптивных атак на основе подобранного шифртекста. При шифровании открытого текста можно дополнительно указать связанные данные, которые должны быть аутентифицированы, но не зашифрованы.

То есть шифрование с соответствующими данными обеспечивает подлинность и целостность данных, но не их секретность.

Однако необходимо отметить, что шифрование добавляется в основном для сокрытия внутренней информации, но очень важно помнить, что первоначальной защитой от подделки токена JWT является подпись, поэтому подпись токена и ее проверка должны быть всегда использованы.

Хранение токенов на стороне клиента

Если приложение хранит токен так, что возникает одна или несколько из следующих ситуаций:

токен автоматически отправляется браузером (сookie storage);
токен получается, даже если браузер перезапущен (использование контейнера localStorage браузера);
токен получается в случае атаки XSS (сookie, доступный для кода JavaScript или токен, который хранится в localStorage или sessionStorage).

Хранить токен в браузере, используя контейнер sessionStorage.
Добавить его в заголовок Authorization, используя схему Bearer. Заголовок должен выглядеть следующим образом:

Authorization: Bearer

Остается случай, когда злоумышленник использует контекст просмотра пользователя в качестве прокси-сервера, чтобы использовать целевое приложение через легитимного пользователя, но Content Security Policy может предотвратить связь с непредвиденными доменами.

Также возможно реализовать службу аутентификации таким образом, чтобы токен выдавался внутри защищенного файла cookie, но в этом случае должна быть реализована защита от CSRF.

Использование слабого ключа при создании токена

Если секрет, используемый в случае алгоритма HMAC-SHA256, необходимый для подписи токена, является слабым, то он может быть взломан (подобран c помощью атаки грубой силы). В результате злоумышленник может подделать произвольный действительный токен с точки зрения подписи.

Для предотвращения этой проблемы надо использовать сложный секретный ключ: буквенно-цифровой (смешанный регистр) + специальные символы.

Поскольку ключ необходим только для компьютерных вычислений, размер секретного ключа может превышать 50 позиций.

A&'/>Z57M(2hNg=;LE?~]YtRMS5(yZ2j:ZeX-BGftaVk`)jKP~q?,jk)EMbgt*kW'

Для оценки сложности секретного ключа, используемого для вашей подписи токена, вы можете применить атаку по словарю паролей к токену в сочетании с JWT API.

How to validate a JWT token

I’m trying to use JWT tokens. I managed to generate a valid JWTTokenString and validated it on the JWT debugger but I’m having an impossible time validating the token in .Net. Here’s the code I have so far:

class Program < static string key = "401b09eab3c013d4ca54922bb802bec8fd5318192b0a75f201d8b3727429090fb337591abd3e44453b954555b7a0812e1081c39b740293f765eae731f5a65ed1"; static void Main(string[] args) < var stringToken = GenerateToken(); ValidateToken(stringToken); >private static string GenerateToken() < var securityKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(key)); var credentials = new SigningCredentials(securityKey, SecurityAlgorithms.HmacSha256); var header = new JwtHeader(credentials); var payload = new JwtPayload < < "some ", "hello ">, < "scope", "world">, >; var secToken = new JwtSecurityToken(header, payload); var handler = new JwtSecurityTokenHandler(); return handler.WriteToken(secToken); > private static bool ValidateToken(string authToken) < var tokenHandler = new JwtSecurityTokenHandler(); var validationParameters = GetValidationParameters(); SecurityToken validatedToken; IPrincipal principal = tokenHandler.ValidateToken(authToken, validationParameters, out validatedToken); Thread.CurrentPrincipal = principal; return true; >private static TokenValidationParameters GetValidationParameters() < return new TokenValidationParameters() < //NOT A CLUE WHAT TO PLACE HERE >; > >

All I want is a function that receives a token and returns true or false based on its validity. From research I’ve seen people use IssuerSigningToken to assign the validation key. But when I try to use it, it doesn’t seem to exist. Could anyone give me a hand on validating the token?