Ответ
JWT — это стандарт (RFC 7519) для создания токенов доступа, состоящих из трех частей в кодировке Base64Url: Header, Payload, Signature. Основные типы различаются по назначению в рамках системы безопасности (чаще всего OAuth 2.0/OpenID Connect).
1. Access Token
- Назначение: Предоставляет доступ к защищенным ресурсам API.
- Характеристики: Короткий срок жизни (минуты/часы). Передается в заголовке
Authorization: Bearer <token>. - Содержимое Payload: Обычно содержит
sub(subject),scope(права доступа),exp(время истечения).
2. Refresh Token
- Назначение: Используется для получения новой пары Access/Refresh токенов без повторного ввода учетных данных пользователя.
- Характеристики: Долгий срок жизни, хранится максимально безопасно (например, в HttpOnly cookie). Не используется для прямых запросов к API.
3. ID Token
- Назначение: Используется в OpenID Connect для передачи информации о пользователе клиентскому приложению.
- Характеристики: Предназначен для клиента, а не для ресурсного сервера. Содержит claims о пользователе (
name,email).
Пример структуры и использования:
// Декодированный JWT (Access Token)
Header: {
"alg": "HS256",
"typ": "JWT"
}
Payload: {
"sub": "user123",
"name": "Alice",
"exp": 1678901234,
"scope": "read write"
}
// Итоговый токен: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNjc4OTAxMjM0LCJzY29wZSI6InJlYWQgd3JpdGUifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cВажно: Access Token должен проверяться ресурсным сервером на валидность подписи и срок действия.
Ответ 18+ 🔞
А, слушай, смотри, про эти ваши JWT, блядь. Ну, ёпта, стандарт такой, бумажка одна, RFC 7519, если по-умному. Суть в том, что это просто три куска текста, склеенные точками и закодированные в Base64Url, чтобы по интернетам летали без проблем. Header, Payload, Signature, блядь. А вот дальше начинается магия, потому что эти токены бывают разные, и если их перепутать — пиши пропало, накроется твой авторизационный сервис медным тазом.
1. Access Token (Токен доступа)
- Зачем нужен: Это, блядь, как пропуск на закрытую вечеринку. Предъявил его API — и тебе открывают дверь к защищённым данным. Всё, что от него нужно — дать доступ.
- Что из себя представляет: Живёт недолго, сука, как мотылёк — минуты, часы. Отправил запрос, прицепил его в заголовок
Authorization: Bearer <token>и понёсся. - Что внутри: В его полезной нагрузке (Payload) обычно сидят
sub(кто ты такой),scope(что тебе можно делать, читать-писать) и святоеexp— время, когда этот кусок бумаги превратится в тыкву.
2. Refresh Token (Токен обновления)
- Зачем нужен: Это, блядь, твой золотой ключик на долгую память. Access Token сдох, а ты не хочешь, чтобы пользователь опять логин-пароль вводил, как лох. Предъявляешь этот refresh — и тебе выдают новую парочку Access/Refresh. Хитрая жопа!
- Что из себя представляет: Живёт долго, хранить его надо как зеницу ока, в идеале — в HttpOnly куках, чтобы клиентский скрипт до него не дотянулся. И главное правило, блядь: его НЕ шлют в API-запросах! Он только для одного дела — выпрашивать новые Access Token'ы.
3. ID Token (Токен идентификации)
- Зачем нужен: Это уже из оперы OpenID Connect. Он не для API, а для самого клиентского приложения, чтобы оно узнало, кто такой этот пользователь. Типа, "привет, я Вася, вот моя почта и аватарка".
- Что из себя представляет: Клиент его получает, проверяет подпись и читает claims о пользователе:
name,emailи прочую лабуду. Ресурсному серверу его совать — моветон, блядь, он для этого не предназначен.
Ну и пример, чтобы вообще всё стало ясно, как божий день:
// Вот так выглядит декодированный Access Token, если его разобрать по косточкам
Header: {
"alg": "HS256", // алгоритм подписи, блядь
"typ": "JWT" // тип — JWT, неожиданно, да?
}
Payload: {
"sub": "user123", // кто
"name": "Alice", // как звать
"exp": 1678901234, // когда подохнет
"scope": "read write" // что можно
}
// А на выходе получается вот такая длиннющая строка, которую все и называют JWT:
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNjc4OTAxMjM0LCJzY29wZSI6InJlYWQgd3JpdGUifQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cИ самое главное, на чём все горят, блядь: Access Token, когда прилетает на ресурсный сервер, надо проверить, ёпта! Подпись целая? Не истёк срок? А то будет смеху — примет сервер просроченную бумажку, и пошёл раздавать данные всем подряд. Пиздец, а не безопасность.