Войти
| Статус | Internet Standard |
|---|---|
| Впервые опубликовано | 28 декабря 2010 г. (2010-12-28) |
| Последняя версия | RFC 7519. Май 2015 |
| Организация | IETF |
| Аббревиатура | JWT |
Веб-токен JSON (JWT, иногда произносится как, то же, что английское слово «jot») - это Интернет-стандарт для создания данных с дополнительной подписью и / или дополнительным шифрованием, полезная нагрузка которых содержит JSON, который утверждает некоторое количество утверждений. Токен подписываются с использованием личного секрета или открытого / закрытого ключа. Например, сервер может сгенерировать токен с утверждением «зарегистрирован как администратор» и предоставить его клиенту. Затем клиент может использовать этот токен, чтобы доказать, что он вошел в систему как администратор. Токены могут быть подписаны закрытым ключом одной стороны (обычно сервером), чтобы эта сторона могла впоследствии проверить, является ли токен законным. Если другая сторона каким-либо подходящим и заслуживающим доверия способом владеет соответствующим открытым ключом, она также может проверить легитимность токена. Маркеры спроектированы так, чтобы быть компактными, URL -безопасными и особенно удобными для использования в веб-браузере единой регистрации ( SSO) контекст. Утверждения JWT обычно могут использоваться для передачи удостоверений аутентифицированных пользователей между поставщиком удостоверений и поставщиком услуг или любого другого типа утверждений в соответствии с требованиями бизнес-процессов.
JWT опирается на другие стандарты на основе JSON: JSON Web Signature и JSON Web Encryption.
| Заголовок | {"alg": "HS256", "typ": "JWT"} | Определяет, какие алгоритм используется для генерации подписи
Типичными используемыми криптографическими алгоритмами являются HMAC с SHA-256 (HS256) и подпись RSA с SHA-256 (RS256). JWA (веб-алгоритмы JSON) RFC 7518 вводит гораздо больше как для аутентификации, так и для шифрования. |
|---|---|---|
| Полезная нагрузка | {"loggedInAs": "admin", "iat": 1422779638} | Содержит набор претензий. Спецификация JWT определяет семь зарегистрированных имен утверждений, которые являются стандартными полями, обычно включаемыми в токены. Пользовательские утверждения обычно также включаются в зависимости от назначения токена. В этом примере есть стандартное утверждение "Выпущено во время" ( |
| Подпись | HMAC-SHA256 (секрет, base64urlEncoding (заголовок) + '.' + Base64urlEncoding (полезная нагрузка)) | Надежно проверяет токен. Подпись вычисляется путем кодирования заголовка и полезной нагрузки с использованием Base64url Encoding и объединения их вместе с разделителем периодов. Эта строка затем проходит через криптографический алгоритм, указанный в заголовке, в данном случае HMAC-SHA256. Кодировка Base64url аналогична кодировке base64, но использует другие не буквенно-цифровые символы и пропускает заполнение. |
Три части кодируются отдельно с использованием Base64url Encoding и объединяются с использованием точек для создания JWT:
const token = base64urlEncoding (header) + '.' + base64urlEncoding (полезная нагрузка) + '.' + Base64urlEncoding (подпись)
Приведенные выше данные и секрет "SecretKey" создает маркер:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
Этот полученный маркер может быть легко передается в HTML и HTTP.
При аутентификации, когда пользователь успешно входит в систему, используя свои учетные данные, будет возвращен веб-токен JSON, который должен быть сохранен локально (обычно в локальное хранилище или хранилище сеанса, но также можно использовать файлы cookie ) вместо традиционного подхода создания сеанса на сервере и возврата файла cookie. Для автоматических процессов клиент также может аутентифицироваться напрямую, создавая и подписывая свой собственный JWT с предварительно общим секретом и передавая его в службу, совместимую с oAuth, например:
POST / oautdiv class="ht" / token? Content-type: application / x-www-form-urlencoded grant_type = urn: ietf: params: oauth: grant-type: jwt-bearer assertion = eyJhb...
Если клиент передает действительное утверждение JWT, сервер сгенерирует токен доступа, действительный для вызова приложения и передачи его клиенту:
{"access_token": "eyJhb...", "token_type": "Bearer", "expires_in": 3600}Когда клиент хочет получить доступ к защищенному маршруту или ресурсу, пользовательский агент должен отправить JWT, обычно в заголовке Authorization, используя схему Bearer. Содержимое заголовка может выглядеть следующим образом:
Авторизация: носитель eyJhbGci...... yu5CSpyHI
Это механизм аутентификации без сохранения состояния, поскольку состояние пользователя никогда не сохраняется. в памяти сервера. Защищенные маршруты сервера будут проверять наличие действительного JWT в заголовке авторизации, и если он присутствует, пользователю будет разрешен доступ к защищенным ресурсам. Поскольку JWT являются самодостаточными, вся необходимая информация имеется, что снижает необходимость многократного запроса базы данных.
Интернет-черновики определяют следующие стандартные поля («заявки»), которые можно использовать внутри набора заявок JWT:
| код | имя | описание |
|---|---|---|
iss | Issuer | Определяет принципала, выдавшего JWT. |
sub | Subject | Определяет тему JWT. |
aud | Аудитория | Определяет получателей, для которых предназначен JWT. Каждый принципал, предназначенный для обработки JWT, должен идентифицировать себя со значением в заявлении аудитории. Если принципал, обрабатывающий утверждение, не идентифицирует себя со значением в утверждении aud, когда это утверждение присутствует, то JWT должен быть отклонен. |
exp | Expiration Time | Определяет время истечения, по истечении которого JWT не должен приниматься для обработки. Значение должно быть NumericDate: целым или десятичным, представляющим секунды после 1970-01-01 00: 00: 00Z. |
nbf | Not Before | Определяет время, в которое JWT начнет приниматься в обработку. Значение должно быть NumericDate. |
iat | Выпущено в | Определяет время, в которое был выдан JWT. Значение должно быть NumericDate. |
jti | JWT ID | Уникальный идентификатор токена с учетом регистра, даже среди разных эмитентов. |
В заголовке JWT обычно используются следующие поля:
| код | имя | описание |
|---|---|---|
тип | Тип токена | Если присутствует, рекомендуется установить его на JWT. |
cty | Тип содержимого | Если используется вложенная подпись или шифрование, рекомендуется установить это на JWT; в противном случае опустите это поле. |
alg | Алгоритм кода аутентификации сообщения | Эмитент может свободно установить алгоритм для проверки подписи на токене. Однако некоторые поддерживаемые алгоритмы небезопасны. |
kid | Key ID | Подсказка, указывающая, какой ключ клиент использовал для генерации подписи токена. Сервер сопоставит это значение с ключом в файле, чтобы убедиться, что подпись действительна и токен подлинен. |
x5c | цепочка сертификатов x.509 | Цепочка сертификатов в формате RFC4945, соответствующая закрытому ключу, используемому для генерации подписи токена. Сервер будет использовать эту информацию для проверки того, что подпись действительна, а токен подлинен. |
x5u | URL цепочки сертификатов x.509 | URL-адрес, по которому сервер может получить цепочку сертификатов, соответствующую закрытому ключу, используемому для генерации подписи токена. Сервер получит и использует эту информацию для проверки подлинности подписи. |
crit | Critical | Список заголовков, которые должны быть поняты сервером, чтобы принять токен как допустимый |
.
Существуют реализации JWT для многих языков и фреймворки, включая, помимо прочего:
веб-токены JSON могут содержать состояние сеанса. Но если требования проекта допускают аннулирование сеанса до истечения срока действия JWT, службы больше не могут доверять утверждениям токена только по токену. Чтобы убедиться, что сеанс, хранящийся в токене, не отменен, утверждения токена должны быть проверены по хранилищу данных . Это делает токены более не безгражданскими, что подрывает основное преимущество JWT.
Консультант по безопасности Тим Маклин сообщил об уязвимостях в некоторых библиотеках JWT, которые использовали поле algдля неправильной проверки токенов. Хотя эти уязвимости были исправлены, Маклин предложил полностью отказаться от поля alg, чтобы предотвратить подобную путаницу при реализации.
При правильном проектировании разработчики могут устранить уязвимости алгоритмов, приняв меры предосторожности:
Архитектор безопасности программного обеспечения Курт Родармер указывает на дополнительные уязвимости конструкции JWT, связанные с ключами криптографической подписи, и на значительную уязвимость, которая обнаруживает парсер JSON библиотеки для открытия атаки. Это прямой результат выбора JSON для выражения заголовка токена, и его труднее смягчить.
