Ответ
Содержимое Access и Refresh токенов определяется их назначением и стандартами, такими как JWT (RFC 7519) для Access токенов.
Access Token (Токен доступа)
Обычно представляет собой JWT (JSON Web Token). Он является самодостаточным и содержит всю необходимую информацию (claims) для авторизации запроса на сервере. Его не нужно проверять по базе данных при каждом запросе, достаточно проверить цифровую подпись.
Стандартные поля (claims):
sub(Subject): Идентификатор пользователя (например,user_id).exp(Expiration Time): Время истечения срока действия токена (в формате Unix timestamp).iat(Issued At): Время выпуска токена.iss(Issuer): Идентификатор сервиса, выдавшего токен.aud(Audience): Идентификатор сервиса, для которого предназначен токен.scope: Область разрешенных действий (например,read:data write:data).
Пример декодированного JWT payload:
{
"sub": "1234567890",
"name": "John Doe",
"email": "john.doe@example.com",
"roles": ["admin", "user"],
"iat": 1516239022,
"exp": 1516242622
}Refresh Token (Токен обновления)
В отличие от Access Token, Refresh Token чаще всего является непрозрачной (opaque), длинной, криптографически случайной строкой. Он не содержит данных о пользователе и его правах.
- Назначение: Безопасное получение нового Access Token после того, как старый истек.
- Хранение: Хранится в базе данных на сервере в связке с пользователем и имеет длительный срок жизни (дни, недели, месяцы).
- Структура: Обычно не имеет внутренней структуры. Это просто уникальный идентификатор сессии.
Пример: v2.local.E-k7sAULEA-C_qAazqJdxJc_234234...
Ответ 18+ 🔞
Давайте разберемся, что у нас тут за токены, а то народ путается, как пьяный в луже. Это ж не просто хуйня какая-то, а целая система, блядь!
Access Token (Токен доступа)
Это, грубо говоря, ваш пропуск на вечеринку. Обычно это JWT (JSON Web Token), ёпта. Вещь самодостаточная, как я после третьей рюмки. Серверу не надо бегать в базу его проверять — он сам себе и паспорт, и виза. Главное, чтобы подпись была правильная, а то пиздец настанет.
Что внутри у этого пропуска (стандартные поля):
sub(Subject): Кто ты такой, твой ID. Типа, "я — Вася Пупкин, user_id 228".exp(Expiration Time): Когда этот пропуск превратится в тыкву. Время в формате "сколько секунд с 1970 года прошло, блядь".iat(Issued At): А когда его, сука, выдали-то?iss(Issuer): Кто этот бланк напечатал (название сервиса).aud(Audience): А кому этот бланк показывать-то надо?scope: Что тебе можно делать? Почитать, пописать, админку потрогать.
Вот смотри, как он выглядит изнутри, если его распаковать:
{
"sub": "1234567890",
"name": "John Doe",
"email": "john.doe@example.com",
"roles": ["admin", "user"],
"iat": 1516239022,
"exp": 1516242622
}Видишь? Всё про тебя написано. Живи не хочу, пока exp не наступил.
Refresh Token (Токен обновления)
А вот это уже хитрая жопа. Это не пропуск, а, блядь, ключ от сейфа, где лежат новые пропуска. Он обычно — непрозрачная, длинная, случайная строка, как бред алкоголика. Никакой информации о тебе внутри нет, одна криптография.
- Зачем нужен: Твой Access Token сдох (истек
exp), а тебе лень заново логиниться. Ты суёшь этот Refresh Token серверу и говоришь: "На, обнови мне пропуск, я тут свой". - Где живёт: Лежит привязанным к твоей учетке в базе данных сервера. Живёт долго, как черепаха — дни, недели, может, месяцы.
- Как выглядит: Просто хуйня-строка, идентификатор сессии. Никакого JSON'а.
Пример: v2.local.E-k7sAULEA-C_qAazqJdxJc_234234...
Вот и вся магия, ёпта. Один — быстрый пропуск с данными, второй — долгий ключ для его обновления. Главное, не перепутай, а то вместо доступа получишь по ебалу от системы.