Аутентификационный токен не прошел проверку unable to verify jwt exp что значит

Пять простых шагов для понимания JSON Web Tokens (JWT)

Представляю вам мой довольно вольный перевод статьи 5 Easy Steps to Understanding JSON Web Tokens (JWT). В этой статье будет рассказано о том, что из себя представляют JSON Web Tokens (JWT) и с чем их едят. То есть какую роль они играют в проверке подлинности пользователя и обеспечении безопасности данных приложения.

Для начала рассмотрим формальное определение.

JSON Web Token (JWT) — это JSON объект, который определен в открытом стандарте RFC 7519. Он считается одним из безопасных способов передачи информации между двумя участниками. Для его создания необходимо определить заголовок (header) с общей информацией по токену, полезные данные (payload), такие как id пользователя, его роль и т.д. и подписи (signature).
Кстати, правильно JWT произносится как /dʒɒt/

Простыми словами, JWT — это лишь строка в следующем формате header.payload.signature .
Предположим, что мы хотим зарегистрироваться на сайте. В нашем случае есть три участника — пользователь user , сервер приложения application server и сервер аутентификации authentication server . Сервер аутентификации будет обеспечивать пользователя токеном, с помощью которого он позднее сможет взаимодействовать с приложением.

Приложение использует JWT для проверки аутентификации пользователя следующим образом:

1. Сперва пользователь заходит на сервер аутентификации с помощью аутентификационного ключа (это может быть пара логин/пароль, либо Facebook ключ, либо Google ключ, либо ключ от другой учетки).
2. Затем сервер аутентификации создает JWT и отправляет его пользователю.
3. Когда пользователь делает запрос к API приложения, он добавляет к нему полученный ранее JWT.
4. Когда пользователь делает API запрос, приложение может проверить по переданному с запросом JWT является ли пользователь тем, за кого себя выдает. В этой схеме сервер приложения сконфигурирован так, что сможет проверить, является ли входящий JWT именно тем, что был создан сервером аутентификации (процесс проверки будет объяснен позже более детально).

Структура JWT

JWT состоит из трех частей: заголовок header , полезные данные payload и подпись signature . Давайте пройдемся по каждой из них.

Шаг 1. Создаем HEADER

Хедер JWT содержит информацию о том, как должна вычисляться JWT подпись. Хедер — это тоже JSON объект, который выглядит следующим образом:

Поле typ не говорит нам ничего нового, только то, что это JSON Web Token. Интереснее здесь будет поле alg , которое определяет алгоритм хеширования. Он будет использоваться при создании подписи. HS256 — не что иное, как HMAC-SHA256 , для его вычисления нужен лишь один секретный ключ (более подробно об этом в шаге 3). Еще может использоваться другой алгоритм RS256 — в отличие от предыдущего, он является ассиметричным и создает два ключа: публичный и приватный. С помощью приватного ключа создается подпись, а с помощью публичного только лишь проверяется подлинность подписи, поэтому нам не нужно беспокоиться о его безопасности.

Шаг 2. Создаем PAYLOAD

Payload — это полезные данные, которые хранятся внутри JWT. Эти данные также называют JWT-claims (заявки). В примере, который рассматриваем мы, сервер аутентификации создает JWT с информацией об id пользователя — userId.

Мы положили только одну заявку (claim) в payload. Вы можете положить столько заявок, сколько захотите. Существует список стандартных заявок для JWT payload — вот некоторые из них:

• iss (issuer) — определяет приложение, из которого отправляется токен.
• sub (subject) — определяет тему токена.
• exp (expiration time) — время жизни токена.

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

Шаг 3. Создаем SIGNATURE

Подпись вычисляется с использование следующего псевдо-кода:

Алгоритм base64url кодирует хедер и payload, созданные на 1 и 2 шаге. Алгоритм соединяет закодированные строки через точку. Затем полученная строка хешируется алгоритмом, заданным в хедере на основе нашего секретного ключа.

Шаг 4. Теперь объединим все три JWT компонента вместе

Теперь, когда у нас есть все три составляющих, мы можем создать наш JWT. Это довольно просто, мы соединяем все полученные элементы в строку через точку.

Вы можете попробовать создать свой собственный JWT на сайте jwt.io.
Вернемся к нашему примеру. Теперь сервер аутентификации может слать пользователю JWT.

Как JWT защищает наши данные?

Очень важно понимать, что использование JWT НЕ скрывает и не маскирует данные автоматически. Причина, почему JWT используются — это проверка, что отправленные данные были действительно отправлены авторизованным источником. Как было продемонстрировано выше, данные внутри JWT закодированы и подписаны, обратите внимание, это не одно и тоже, что зашифрованы. Цель кодирования данных — преобразование структуры. Подписанные данные позволяют получателю данных проверить аутентификацию источника данных. Таким образом закодирование и подпись данных не защищает их. С другой стороны, главная цель шифрования — это защита данных от неавторизованного доступа. Для более детального объяснения различия между кодированием и шифрованием, а также о том, как работает хеширование, смотрите эту статью. Поскольку JWT только лишь закодирована и подписана, и поскольку JWT не зашифрована, JWT не гарантирует никакой безопасности для чувствительных (sensitive) данных.

Шаг 5. Проверка JWT

В нашем простом примере из 3 участников мы используем JWT, который подписан с помощью HS256 алгоритма и только сервер аутентификации и сервер приложения знают секретный ключ. Сервер приложения получает секретный ключ от сервера аутентификации во время установки аутентификационных процессов. Поскольку приложение знает секретный ключ, когда пользователь делает API-запрос с приложенным к нему токеном, приложение может выполнить тот же алгоритм подписывания к JWT, что в шаге 3. Приложение может потом проверить эту подпись, сравнивая ее со своей собственной, вычисленной хешированием. Если подписи совпадают, значит JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки. Таким образом, проверяя JWT, приложение добавляет доверительный слой (a layer of trust) между собой и пользователем.

В заключение

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

Что дальше?

Подумаем о безопасности и добавим Refresh Token . Смотрите следующую мою статью на эту тему.

Источник

Невозможно пройти проверку подлинности с ошибкой токена в dingo / api с помощью jwt-auth

я использую Динго / апи (который имеет встроенную поддержку JWT-авт ) сделать API.

Предположим, это мои маршруты:

checkPhone метод, имеющий задачу авторизации и создания токена, выглядит так:

А также injectToken() метод на User Модель это:

Создание токена работает нормально.

Но когда я отправляю его на защищенную конечную точку, всегда Unable to authenticate with invalid token встречается,.

Защищенный метод действия конечной точки:

я использовал PostMan как клиент API и отправлять сгенерированные токены в виде заголовка следующим образом:

Я не могу найти решение после многих поисков в сети и связанных репозиториях.

В чем проблема по вашему мнению?

Обновить :

Я обнаружил, что не найдена ошибка для конструктора loginController, который предлагает laravel:

потому что, когда я прокомментировал $this->middleware(‘guest’, [‘except’ => ‘logout’]); все сработало.
Но если я уберу эту строку правильно?
Как должна быть эта строка для API?

Решение

Как я уже упоминал ранее, проблема с обновлением заметки заключалась в том, что я использовал checkPhone а также verifyCode в LoginController, который имеет проверку гостя в своем конструкторе.

И потому что guest промежуточное программное обеспечение относится к \App\Http\Middleware\RedirectIfAuthenticated::class и это перенаправляет вошедшего в систему пользователя на /home каталог, и я не создал это, так 404 error произошло.

Теперь я перенес эти методы в UserController без какого-либо промежуточного программного обеспечения в его конструкторе.

Другие решения

Обновление моего config / api.php для этого сделало свое дело

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

Источник

JWT проверка на стороне клиента?

У меня есть nodejs api с интерфейсом angular. The API успешно использует JWT с паспортом для защиты своих конечных точек.

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

Вот как мой бэкэнд генерирует токен:

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

Q2, библиотека JWT , которую я использую, похоже, требует открытого ключа для использования своей функции verify() . Похоже, у меня нет открытого ключа, только секрет, который я только что придумал, так что он не был сгенерирован с парой. Откуда берется мой открытый ключ, или есть другой способ проверить мой токен без этого?

Все это кажется очевидным и что я что-то упустил, так что прошу прощения, если это глупый вопрос, но я, кажется, не могу найти ответ?

4 ответа

Я создаю приложение android и планирую использовать для аутентификации Json веб-токенов (JWT). Как только мой сервер возвращает ответ с сгенерированным токеном, имеет ли смысл декодировать токен на стороне клиента, чтобы прочитать информацию о пользователе (она же полезная нагрузка), или я должен.

Я много читал о JWT и о том, как создавать stateless сеансов через JWT. Суть того, что я понимаю, заключается в том, что из-за истечения срока действия подписи & вы можете по существу отправить весь сеанс для сохранения клиентом, и серверу не нужно поддерживать базу данных, чтобы запомнить.

TL;DR

1. Вы должны всегда проверять подпись JWS на сервере .
2. Проверка подписи на стороне клиента мало что дает, если только у вас нет конкретного случая, когда имеет смысл этого не делать .
3. Вам не нужно проверять подпись токена JWS, чтобы проверить срок действия в клиенте. (если вы не шифровали утверждения, то есть не использовали JWE, в этом случае вам нужно сделать что-то подобное, потому что вам нужен ключ для расшифровки утверждений).
4. Вам также не нужно проверять подпись JWS, чтобы проверить срок действия на сервере, но вы должны это сделать, потому что это дает вам уверенность в том, что никто не изменил срок действия (в противном случае проверка завершится неудачей, потому что если утверждения изменятся, то пересчитанная подпись будет отличаться)
5. Чтобы прочитать не зашифрованные утверждения, вам просто нужно их расшифровать. Вы можете использовать jwt-decode в клиенте.

Теперь я осознаю, что после истечения срока действия токенов мой интерфейс все равно позволит пользователю запрашивать мои api конечных точек [. ]

Поэтому, чтобы реализовать эту логику, я думаю, мне нужно проверить клиентскую сторону токена JWT

Если я правильно вас понял, вы говорите о проверке того, истек ли срок действия JWS на стороне клиента. Для этого вам не нужно проверять подпись токена (хотя библиотека, которую вы используете, кажется, делает для вас обе вещи одновременно , но также позволяет отключить контроль истечения срока действия с флагом ignoreExpiration ). (Если вы не шифруете утверждения, то есть используете JWE) В RFC 7515 (JWS) ничего не говорится об истечении срока действия. Подпись сообщения или проверка MAC не контролируют срок действия (и не должны, потому что подписи обеспечивают подлинность и целостность). Даже RFC 7519 (JWT) не контролирует требование истечения срока действия для разрешения, является ли JWT действительным или нет .

Таким образом, вы можете проверить, истек ли срок действия JWT или нет, не проверяя подпись, поэтому вам не нужен ни открытый ключ (для асимметричного шифрования, например RSA), ни секретный ключ (для симметричного шифрования, например AES). В токенах JWT и JWS утверждения просто закодированы открытым текстом base64, поэтому вы можете просто декодировать полезную нагрузку, не проверяя, действительна ли подпись , и прочитать утверждение об истечении срока действия. Если вы шифруете полезную нагрузку (он же использует JWE), вы не сможете этого сделать.

Записка из библиотеки jjwt

JWTs может быть криптографически подписан (что делает его JWS ) или зашифрован (что делает его JWE ).

Вот библиотека ligthweigth от auth0 для декодирования base64encoded утверждений токена JWT/JWS . Один парень даже спрашивает о проверке срока годности .

Я не знаю, почему вы думаете, что должны делать это на стороне клиента, единственное преимущество заключается в том, чтобы избежать отправки запроса API, который, как знает клиент, завершится неудачей. И они должны потерпеть неудачу, потому что сервер должен проверить, что срок действия токена не истек, очевидно, предыдущая проверка подписи (с секретным/закрытым ключом).

В RFC 7519 говорится об этом заявлении:

Утверждение «exp» (время истечения срока действия) определяет время истечения срока действия на или после чего JWT НЕ ДОЛЖЕН быть принят к обработке .

В веб-приложении, подобном тому, о котором вы говорите, использование токенов позволяет серверам без состояния проверять подлинность клиентских запросов. Цель утверждения об истечении срока действия OPTIONAL состоит в том, чтобы позволить серверу иметь некоторый контроль над сгенерированным JWS (если мы используем JWT для аутентификации, подписывая их, необходимо, поэтому мы должны говорить о JWS).

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

Недействительность сеанса становится реальной проблемой, если мы включаем информацию в полезную нагрузку JWS (aka утверждения), используемую для авторизации, например, какие роли есть у пользователя.

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

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

Злоумышленник, использующий CSRF, сможет сделать запрос с истекшим сроком действия JWS на ваш API, пропустив контроль истечения срока действия.

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

Что касается вашего вопроса

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

Метод проверки, на который вы указали, прямо говорит, что он принимает открытый или секретный ключ.

secretOrPublicKey-это строка или буфер, содержащий либо секрет для алгоритмов HMAC, либо закодированный открытый ключ PEM для RSA и ECDSA

Я предполагаю, что вы не используете ни то, ни другое, и вы используете строку типа ‘shhhh’.

Тогда вы должны сделать

Однако здесь возникает вопрос: действительно ли необходима проверка подписи на стороне клиента?

Я думаю, что это не так, по крайней мере, не для такого рода приложений, где клиент просто использует JWS для отправки последующего запроса на сервер со словами: «Эй, сервер, я Габриэль, и у меня есть бумага (токен), которая гарантирует, что и эта бумага подписана вами.» Таким образом, если клиент не проверяет JWS, а MITM успешно передал этому клиенту JWS, подписанный им самим (вместо JWS, подписанного сервером), то последующий запрос просто завершится неудачей. Как и контроль истечения срока действия, проверка подписи только предотвращает отправку клиентом запроса, который завершится неудачей.

Теперь проверка на стороне клиента требует отправки открытого или секретного ключа. Отправка открытого ключа не представляет проблемы безопасности, но это дополнительные усилия и обработка с небольшими преимуществами.

Отправка секретных ключей (например, ‘shhhh’) может представлять проблему безопасности, поскольку это тот же ключ, который используется для подписи токенов.

Я использую токен jwt для аутентификации и хотел бы прочитать информацию о полезной нагрузке на стороне клиента. Прямо сейчас я делаю что-то вроде этого: var payload = JSON.parse(window.atob(token.split(‘.’)[1])); Есть ли лучший способ работать с токенами jwt в браузере?

Я понимаю, что JWT может содержать некоторую информацию о роли пользователя, которая должна быть проверена на сервере , например, в scope , так что пользователь, не являющийся ролью, не сможет получить доступ к данным с определенных конечных точек, защищенных этой ролью. < iss: http://issuer.com.

Я думаю, что проверка токена JWT на стороне клиента-не очень хорошая идея.
IMO;

Всякий раз, когда пользователь входит в систему, генерируйте маркер доступа и обновления и возвращайте пользователю что-то вроде этого;

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

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

Q1: Проверка токенов на клиенте-плохая идея. Что вы можете сделать, так это сохранить токен вместе с той же датой истечения срока действия на клиенте, а затем обновить/удалить токен. Но я подумал, что лучше иметь некоторую проверку даты на стороне сервера, потому что существует простое правило: не доверяйте клиенту , потому что он всегда может отправить вредоносный код.

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

Ответ 1 : Это не считается хорошим подходом для проверки вашего токена аутентификации на стороне клиента, поскольку он включает в себя секретный ключ, в то время как его кодирование/декодирование и хранение секретного ключа на стороне клиента небезопасно .

Создание токена

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

Ответ 2 : JWT включает секретный ИЛИ открытый ключ при кодировании и декодировании токена. Он должен быть объявлен или сохранен в конфигурационном файле где-то на стороне сервера.

Объяснение: Декодирование означает декодирование из Base64, в этом процессе нет секретного ключа. С другой стороны, для проверки JWT потребуется секретный ключ, поскольку для этого потребуется операция криптографической подписи.

Подводя итог, декодирование не нуждается в секрете (помните, что декодирование-это просто интерпретация base64), и проверка/подпись действительно требует этого

Похожие вопросы:

Зачем нам нужна проверка как на стороне клиента, так и на стороне сервера ? я читал, что и то, и другое необходимо по соображениям безопасности.. так что если проверку на стороне клиента можно.

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

В настоящее время я смотрю обучающие видео на ASP .NET MVC 3 и пришел к разделу о включении и отключении проверки на стороне клиента. Мой вопрос заключается в том, почему вы когда-либо хотели.

Я создаю приложение android и планирую использовать для аутентификации Json веб-токенов (JWT). Как только мой сервер возвращает ответ с сгенерированным токеном, имеет ли смысл декодировать токен на.

Я много читал о JWT и о том, как создавать stateless сеансов через JWT. Суть того, что я понимаю, заключается в том, что из-за истечения срока действия подписи & вы можете по существу отправить.

Я использую токен jwt для аутентификации и хотел бы прочитать информацию о полезной нагрузке на стороне клиента. Прямо сейчас я делаю что-то вроде этого: var payload =.

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

Я использую узел js для проверки пользователя и отправки обратно токена JWT. Я использую Angular 6.0 для переднего конца. Мой вопрос заключается в том, где хранить этот токен на стороне клиента? и.

Я использую PassportJS для реализации стратегии авторизации JWT в приложении NodeJS/Express. Во всех учебных пособиях токен JWT просто отправляется обратно по маршруту POST /login и вручную.

Я довольно новичок в JWT, и мне нужно его реализовать. Мы используем angular на клиенте и PHP с композитором на бэкэнде. Я уже знаю основы верификации и формирования токенов. Таким образом, я могу.

Источник