Сессионный токен и другие типы токенов

Привет!

Возможно, вы встречали слово “токен” в техническом задании или в разговоре с разработчиками. Давайте разберемся, что это такое на простых примерах - без лишних технических деталей.

Представьте, что вы пришли в фитнес-клуб. Вы показали паспорт на входе, и вам дали браслет. Дальше - вы просто показываете браслет, и вас пускают в зал, бассейн, раздевалку. Не нужно каждый раз доставать паспорт и доказывать, что вы - это вы. Токен - это тот самый браслет, только для интернета :)

Технически это просто строка с набором символов. Например: dkwfWxbc0SU32nNEDjKzqdkwfWxb. Когда вы вводите логин и пароль на сайте (показываете паспорт), сервер выдает вам токен (браслет). И дальше при каждом действии вы просто показываете этот токен - не нужно вводить пароль снова и снова.

Токен хранится в cookies вашего браузера (да, те самые “печеньки”, про которые все говорят). Я только что открыл vk.com - и вот, вижу свой пользовательский токен в настройках браузера :)

Это как положить браслет от фитнес-клуба в карман - он всегда при вас, вы его не видите, но он работает.

Сессионный токен - это самый распространенный тип. Когда вы заходите в соцсеть ВКонтакте, вам выдается такой токен. Сервер создает его и хранит у себя в базе данных. Когда вы делаете запрос, сервер проверяет: “О, этот токен я знаю, это Иван Иванов”. Пока вы не закрыли браузер (или не вышли из аккаунта), этот токен позволяет вам листать ленту, писать комментарии, ставить лайки. Обычно такой токен живет до тех пор, пока вы не закроете браузер, или пока не истечет заданное время - например, 24 часа. Выглядит он примерно так: sess_9f86d081884c7d659a2feaa0c55ad015

Дальше - больше. Есть более “умные” токены, которые называются JWT (JSON Web Token). Вся информация о пользователе зашифрована прямо внутри такого токена. Серверу не нужно хранить его в базе - он просто читает, что написано внутри. Это как QR-код на билете в кино - в нем уже записано: фильм, время сеанса, ряд, место. Кассиру не нужно лезть в базу данных, он просто сканирует код и видит всю информацию.

JWT токен состоит из трех частей, разделенных точками: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikl2YW4gSXZhbm92IiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Видите? Первая часть - тип токена, вторая - данные пользователя, третья - подпись для проверки. Обычно такие токены живут недолго - от 15 минут до 1 часа, потом их нужно обновить.

А вот тут появляется интересная штука - refresh token (токен обновления). Это “запасной ключ”. Представьте, что у вас есть пропуск в офис на один день (основной токен) и долгосрочный договор с охраной (refresh token). Каждое утро вы показываете договор и получаете новый дневной пропуск. Вы получаете сразу два токена: короткий (основной, живет 15 минут) и длинный (запасной, живет 30 дней). Основной используете для работы, запасной - только для получения нового основного. Когда основной истекает, вы показываете запасной и получаете новый основной - не нужно вводить пароль снова. Выглядит так: refresh_a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6

Тем не менее, есть токены не для людей, а для программ - API токены. Допустим, вы хотите, чтобы ваш сайт показывал погоду. Вы регистрируетесь на сервисе погоды, получаете API ключ (например, sk_live_51H2fT2LmGbKq3bYdM8VnZxP4F6Rg9Wq), и ваш сайт каждый час автоматически запрашивает данные, используя этот ключ. Или вы настраиваете автоматическую публикацию постов в Telegram-канал - вы получаете Bot Token от Telegram и настраиваете свою программу. Такие токены обычно живут очень долго или вообще бессрочно. Вы можете отозвать их в любой момент в настройках. Вы встретите их везде: Яндекс.Карты API, Google Analytics API, Telegram Bot API, платежные системы вроде Stripe или PayPal.

Также существуют одноразовые токены (one-time token) - они работают только один раз. Использовал - и всё, он больше не действует. Классический пример - восстановление пароля. Вы нажали “Забыли пароль?”, вам пришло письмо со ссылкой типа https://site.com/reset-password?token=a1b2c3d4e5f6g7h8. Вы кликнули, ввели новый пароль - токен сгорел. Если кто-то попробует использовать ту же ссылку через 5 минут - она уже не сработает. То же самое с подтверждением email при регистрации, с двухфакторной аутентификацией (код из SMS), со ссылкой для скачивания файла. Такие токены живут недолго - обычно от 15 минут до 1 часа, или до первого использования.

Ну и еще один момент - bearer token. Это не отдельный тип токена, а способ его передачи. “Bearer” означает “носитель” - тот, кто носит этот токен, имеет доступ. Это как билет на концерт: у кого билет, тот и проходит. Неважно, как вы его получили (купили сами, вам подарили, нашли) - охрана просто проверяет наличие билета. Токен передается в заголовке HTTP-запроса в специальном формате: Authorization: Bearer dkwfWxbc0SU32nNEDjKzqdkwfWxb. Практически везде в современных API используется именно этот способ. OAuth 2.0 (когда вы входите через Google, Facebook, Яндекс) тоже использует bearer token.

От чего зависит время жизни токена? От того, насколько мы доверяем нашему пользователю и насколько нам нужно защитить данные. В интернет-банке токен может жить всего 15-30 минут - деньги же, высокий риск. На Госуслугах - 1 час (персональные данные, документы). В соцсетях вроде ВКонтакте или Instagram - 1-3 месяца, потому что удобство важнее, а данные не настолько критичные. На YouTube токен может жить до года - просмотр видео не несет большого риска. В корпоративной системе обычно ставят 8 часов (рабочий день) - баланс между безопасностью и удобством.

Тем не менее, помните: даже если токен живет год, пользователь всегда может выйти из системы вручную (тогда токен удаляется сразу).

С чем важно быть аккуратным? Токены нельзя передавать кому-то - это как пароль. Если кто-то получит ваш токен, он сможет действовать от вашего имени. Также токены не должны попадать в URL (плохо: https://site.com/profile?token=abc123) - лучше хранить их в cookies или в заголовке запроса. Почему? URL сохраняется в истории браузера, логах сервера, может попасть в поисковую систему. Используйте HTTPS - токены должны передаваться только по защищенному соединению, иначе их могут перехватить. И не используйте один и тот же токен для всего - API токен отдельно, сессионный токен отдельно.

Когда вы пишете требования к системе аутентификации, важно указать: тип токена (JWT, сессионный, или что-то еще), время жизни (сколько токен будет действителен), где хранится (cookies, localStorage, заголовки), что делать при истечении (показать форму входа или автоматически обновить через refresh token), можно ли иметь несколько активных токенов (например, войти с телефона и компьютера одновременно).

Пример формулировки: “Система должна использовать JWT токены с временем жизни 1 час. При истечении токена система автоматически обновляет его через refresh token (время жизни 30 дней). Пользователь может иметь до 5 активных сессий одновременно (разные устройства).”

Надеюсь, теперь понятнее, что такое токены и какие они бывают :) Если встретите в техническом задании фразу “нужна поддержка JWT токенов с refresh token” - вы уже будете знать, о чем речь.

p.s. В следующий раз, когда разработчик скажет “у вас токен истек”, вы будете знать, что это примерно как “ваш браслет в фитнес-клубе больше не действует, нужно получить новый” :)