Ответы пользователя по тегу JSON Web Token
  • Можно ли обойти аутентификацию JWT, если знаешь секретное слово, но не знаешь timestamp?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Если вы меняете заголовок или полезную нагрузку токена, то должны вычислить новую подпись.
    Для начала изучите, что такое JWT.
    Потом научитесь вычислять подпись токена по HS256 (HMAC with SHA-256).
    А уже потом пытайтесь подобрать секретный ключ.
    Ответ написан
  • Куки и jwt токен как с этим работать?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Рабочий JWT в базе не хранится. Он отдаётся клиенту и предъявляется при каждом запросе к серверу. Защитой служит цифровая подпись токена (третий фрагмент), закрытый ключ которой известен только серверу, выдавшему токен.
    Ответ написан
    Комментировать
  • Как правильно организовать обновление пар JWT + RT в API для нескольких клиентов?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    В SPA в пределах одной страницы это реализуется примерно так:
    var isRefreshing = null;
    var refreshingCall = null;
    async function request() {
      while (true) {
        if (isRefreshing) {
          const refreshed = await refreshingCall;
          isRefreshing = false;
        }
        const response = await fetch(...);
        const data = await response.json();
        if (!data.needRefresh) {
          return data;
        }
        isRefreshing = true;
        refreshingCall = doRefresh(...);
      }
    }
    
    async function doRefresh(...) {
      ...
    }
    Основная идея - использование глобального флага обновления токена и глобальной переменной с промисом. Первый запрос, обнаруживший необходимость обновления, выставляет флаг и записывает промис, который возвращает функция обновления. Второй (и последующие) запрос видит, что флаг уже стоит и просто ждёт выполнения промиса.
    Ответ написан
  • Как корректно использовать пару JWT и Refresh токенов?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Следить за сроком жизни может как клиент, так и сервер или оба.
    В первом случае клиент, обнаружив просроченный токен доступа, сразу отправляет запрос на обновление. Недостаток - если на клиенте перевести часы назад, то он не обнаружит протухший токен.
    Во втором случае время всегда берётся с одного источника (сервера), но будет лишний запрос, на который сервер ответит, что токен просрочен.
    Ответ написан
    Комментировать
  • Как правильно использовать refresh token на разных устройствах?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Каждое устройство - отдельный клиент и получает свою пару токенов. В отдельную таблицу базы пишутся записи (id_пользователя, refresh_токен, время_окончания_токена, статус).
    При запросе обновления если этот токен отмечен в базе как использованный, то все токены клиента удаляются из базы как скомпрометированные и возвращается требование аутентификации по логину/паролю.
    Если токен просрочен или его нет в базе, то возвращается требование аутентификации по логину/паролю.
    Если токен есть в базе и ещё не использован, то токен отмечается как использованный и выдаётся новая пара токенов.
    Периодически из базы удаляются токены с истёкшим сроком действия.
    Ответ написан
    5 комментариев
  • Postman и создание админ аккаунтов для сторонних сайтов. Как защитить себя?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Если вы используете корректный JWT, то роль должна хранится в нём. Токен защищён подписью и подставить в него произвольное значение не получится.
    При входе по логину/паролю роль берётся из базы данных, передавать её в форме не надо.
    При создании нового пользователя админом на бэке проверяется роль отправившего запрос (в токене).
    При самостоятельной регистрации нового пользователя принудительно назначается роль "user" и поднять её может только действующий админ.
    Ответ написан
    2 комментария
  • Какой алгоритм работы с JWT token?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    При авторизации выдаются сразу оба токена, рабочий и refresh. Refresh-токен сохраняется в базе сервера вместе с идентификатором пользователя, рабочий токен хранить смысла нет.

    Срок жизни записан в самом токене, как одно из полей полезной нагрузки (payload). Прочитать это поле может и сервер и клиент. Сервер в любом случае должен контролировать срок жизни токена, клиент может это делать сам, а может просто реагировать на ответы сервера.

    Каждый запрос к серверу сопровождается рабочим токеном. Если срок жизни рабочего токена истёк, то сервер возвращает сообщение о необходимости обновления токена.

    Запрос на обновление сопровождается refresh-токеном.
    Если refresh-токен в базе помечен как уже использованный, то инактивируются (удаляются из базы) все refresh-токены данного пользователя и возвращается сообщение о необходимости повторной авторизации.
    Refresh-токен отмечается в базе как использованный .
    Если срок действия refresh-токена истёк или такого refresh-токена нет в базе сервера, то возвращается сообщение о необходимости повторной авторизации.
    Возвращается новая пара токенов.

    Где и как хранить токены на клиенте - вопрос предпочтений. Можно не хранить вообще, тогда при перезагрузке страницы пользователю придётся авторизоваться заново. Можно сохранять только refresh-токен, выполняя запрос на обновление при запуске приложения / открытии страницы.
    Ответ написан
    4 комментария
  • Как обновлять токены авторизации для нескольких устройств?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    При использовании refresh-токен помечается в базе как использованный. При попытке повторно использовать тот же токен удаляются все refresh-токены пользователя и запрашивается логин/пароль.
    Refresh-токен удаляется из базы после истечения срока его жизни.
    Ответ написан
  • Как привязать нужного пользователя к правильной сессии?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    JWT используется в stateless-режимах. Основной токен на сервере не хранится вообще. Он подписан выдающим сервером и, если подпись верна, то рабочий сервер просто доверяет информации в токене.
    Если клиент не прислал токен или прислал просроченный токен или подпись неверна, то в ответ сервер требует авторизацию. Если пришёл действительный токен, то сервер просто использует данные из токена.
    Ответ написан
  • Какой секретный ключ использовать в JWT?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Узнать ключ можно только взломав сервер. В этом случае знание кем-то ключа будет наименьшей из проблем.
    Ответ написан
    Комментировать
  • Как расшифровать JWT токен?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    JWT состоит из трёх частей, разделённых точками. Первая часть - заголовок, вторая - полезная нагрузка (payload), третья часть - подпись. Подпись представляет из себя шифрованный по ключу хэш от первых двух частей.

    При выдаче токена сервер генерирует заголовок и полезную нагрузку, записывает их в JSON и кодирует в модифицированный BASE64. Получается две строки. Эти строки объединяются через точку и от полученной общей строки вычисляется подпись. Конкретный алгоритм вычисления указан в заголовке. Далее подпись через точку присоединяется к строке и получается полный токен.

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

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