Учебная комната Cabbage Java охватывает основные знания
1. Что такое JWT
JSON Web Token (JWT) — это открытый стандарт (RFC 7519), определяющий компактный автономный способ безопасной передачи информации между сторонами в виде объектов JSON. Эту информацию можно проверить и доверять ей, поскольку она имеет цифровую подпись.
JWT разработан, чтобы быть компактным и безопасным, особенно для сценариев единого входа (SSO) для распределенных сайтов. Заявки JWT обычно используются для передачи аутентифицированной информации об удостоверении пользователя между поставщиками удостоверений и поставщиками услуг для получения ресурсов с серверов ресурсов, а также могут добавлять некоторую дополнительную информацию о заявке, необходимую для другой бизнес-логики.Можно использовать непосредственно для проверки подлинности или зашифровать.
1.1 Традиционная аутентификация сеанса
Говоря о JWT, мы должны поговорить о разнице между аутентификацией на основе токенов и традиционной сеансовой аутентификацией.
мы знаем,Сам протокол http является протоколом без сохранения состояния., а это значит, что если пользователь предоставляет имя пользователя и пароль нашему приложению для аутентификации пользователя, то в следующий раз, когда пользователь запрашивает, пользователь должен снова выполнить аутентификацию пользователя, потому что по протоколу http мы не можем знать, какой именно это запрос, сделанный пользователем, поэтому для того, чтобы наше приложение могло определить, какой пользователь сделал запрос, мы можем хранить только копию информации для входа пользователя на сервер, и эта информация для входа будет передана браузеру в ответе , сказав ему сохранить его как Файл cookie отправляется нашему приложению при следующем запросе, чтобы наше приложение могло определить, от какого пользователя пришел запрос.Это традиционная аутентификация на основе сеанса.
Однако эта проверка подлинности на основе сеанса затрудняет расширение самого приложения.С увеличением количества различных пользователей-клиентов независимый сервер больше не может обслуживать больше пользователей.В настоящее время проблема приложения проверки подлинности на основе сеанса будет раскрыта.
Проблемы, обнаруженные сеансовой аутентификацией
- Session: После того, как каждый пользователь аутентифицирован нашим приложением, наше приложение должно сделать запись на стороне сервера, чтобы облегчить идентификацию следующего запроса пользователя.Вообще говоря, сессия сохраняется в памяти, и по мере увеличения количества аутентифицированных пользователей, накладные расходы на стороне сервера значительно возрастут.
- Расширяемость: После аутентификации пользователя сервер делает запись аутентификации.Если запись аутентификации хранится в памяти, это означает, что пользователь должен запросить этот сервер в следующий раз, чтобы можно было получить авторизованные ресурсы.В приложении этого тип, мощность балансировщика нагрузки соответственно ограничена. Это также означает, что масштабируемость приложения ограничена.
- CSRF: поскольку идентификация пользователя основана на файлах cookie, в случае их перехвата пользователи будут уязвимы для атак с подделкой межсайтовых запросов.
1.2 Механизм аутентификации на основе токенов
Подобно протоколу http, механизм аутентификации на основе токенов не имеет состояния, и ему не нужно хранить информацию об аутентификации пользователя или информацию о сеансе на стороне сервера. Это означает, что приложениям, основанным на механизме аутентификации по токену, не нужно учитывать, на каком сервере заходит пользователь, что облегчает расширение приложения.
Процесс выглядит следующим образом:
- Пользователь запрашивает сервер с именем пользователя и паролем
- Сервер аутентифицирует информацию пользователя
- Сервер аутентифицирует и отправляет токен пользователю
- Клиент сохраняет токен и прикрепляет значение токена к каждому запросу.
- Сервер проверяет значение токена и возвращает данные
Этот токен должен передаваться серверу при каждом запросе, он должен храниться в заголовке запроса, и сервер должен поддерживатьПолитика CORS (совместное использование ресурсов между источниками), обычно мы делаем это на стороне сервераAccess-Control-Allow-Origin: *
.
2. Как выглядит JWT
JWT состоит из трех частей информации, и эти три части информационного текста используются.
链接一起就构成了Jwt字符串。 так:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
3. Состав JWT
Первую часть мы называем заголовком, вторую часть — полезной нагрузкой (аналогично тому, что перевозится в самолете), а третью часть — сигнатурой.
3.1. header
Заголовок jwt содержит две части информации:
- тип объявлениявот джвт
- Объявить алгоритм шифрованияОбычно HMAC SHA256 используется напрямую
Полный заголовок выглядит как следующий JSON:
{
'typ': 'JWT',
'alg': 'HS256'
}
Затем заголовок шифруется base64 (это шифрование может быть расшифровано симметрично), образуя первую часть.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
3.2. playload
Полезная нагрузка — это место, где хранится достоверная информация. Название, похоже, относится конкретно к грузу, перевозимому на самолете.Достоверная информация состоит из трех частей:
- Заявления, зарегистрированные в стандарте
- публичное заявление
- личное заявление
Заявления, зарегистрированные в стандарте (рекомендуются, но не обязательны):
- iss: эмитент jwt
- sub: Пользователи, на которые нацелен jwt
- aud: Сторона, получающая jwt
- exp: время истечения jwt, это время истечения должно быть больше, чем время выдачи
- nbf: определить до тех пор, пока jwt не будет недоступен
- iat: время выпуска jwt
- jti: Уникальный идентификатор JWT, который в основном используется как одноразовый токен, чтобы избежать атак воспроизведения
публичное заявление:
Публичное заявление может добавлять любую информацию, как правило, информацию, относящуюся к пользователям, или другую необходимую информацию для нужд бизнеса. Но добавлять конфиденциальную информацию не рекомендуется, так как эта часть может быть расшифрована на стороне клиента.
личное заявление:
Частный оператор — это оператор, определяемый совместно поставщиком и потребителем.Как правило, не рекомендуется хранить конфиденциальную информацию, поскольку base64 является симметричным дешифрованием, что означает, что эта часть информации может быть классифицирована как информация открытого текста.
Определите полезную нагрузку:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Затем он шифруется base64, чтобы получить вторую часть JWT.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
3.3. signature
Третья часть jwt — это визовая информация, состоящая из трех частей:
- заголовок (после base64)
- полезная нагрузка (после base64)
- secret
Эта часть требует использования зашифрованного base64 заголовка и зашифрованной полезной нагрузки base64..
Затем объединенная строка шифруется с помощью метода шифрования, объявленного в заголовке, с комбинацией секретов с солью, и затем она составляет третью часть jwt.
String encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload);
String signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Объедините эти три части в полную строку, чтобы сформировать окончательную jwt:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Уведомление:Секрет хранится на стороне сервера, и выдача и генерация jwt тоже на стороне сервера., secret используется для выдачи jwt и проверки jwt, поэтому он является закрытым ключом вашего сервера и не должен раскрываться ни при каких обстоятельствах. Как только клиент узнает этот секрет, это означает, что клиент может самостоятельно выпустить jwt.
4. Как применяется JWT
Обычно добавляется в заголовок запросаAuthorization
, и добавитьBearer
Вызывать:
headers: {
'Authorization': 'Bearer ' + token
}
Сервер проверит токен и, если проверка пройдена, вернет соответствующий ресурс. Весь процесс выглядит так:
5. Преимущества и недостатки JWT
5.1. Преимущества JWT
- Из-за универсальности json JWT может поддерживаться на разных языках, таких как JAVA, JavaScript, NodeJS, PHP и многие другие языки;
- Из-за части полезной нагрузки JWT может хранить в себе некоторую неконфиденциальную информацию, необходимую для другой бизнес-логики;
- Простота передачи, состав jwt очень прост, а занимаемость в байтах очень мала, поэтому его очень легко передавать;
- Не нужно сохранять информацию о сеансе на стороне сервера, поэтому легко применять расширения.
5.2 Недостатки JWT
- Конфиденциальная информация не должна храниться в полезной части jwt, потому что эта часть может быть расшифрована клиентом;
- Защитите секретный закрытый ключ, что очень важно;
- По возможности используйте протокол https.