ИНФО
Выбери режим и войди в систему
Симулятор
токенов авторизации
Практика к лекции «Идентификация, аутентификация и авторизация».
Выбери тип токена — пройди полный цикл входа и посмотри, что происходит под капотом.
Session Token
Сессионный токен
Сервер создаёт session_id после входа. Хранится в Cookie. Передаётся автоматически с каждым HTTP-запросом.
JWT
JSON Web Token
Header.Payload.Signature. Декодируй токен прямо на странице. Хранится в localStorage, передаётся в заголовке.
Access + Refresh
Пара токенов
Access Token (30 сек в демо) + Refresh Token (30 дней). Наблюдай, как Access истекает и тихо обновляется.
API Key
Ключ API
Статичный ключ без входа в систему. Передаётся в заголовке X-API-Key или в URL-параметре.
Basic Auth
Базовая авторизация
Логин и пароль кодируются в Base64 и передаются в заголовке Authorization при каждом запросе.
OAuth 2.0
OAuth — схема потока
Интерактивная схема Authorization Code Flow. Шаг за шагом: пользователь, приложение, Auth Server, API.
💡 DevTools для этого симулятора:
Network — все реальные запросы к httpbin.org (видно заголовки Authorization, X-QO-Session-ID, X-API-Key)
Application → Storage — localStorage и Cookies (qo_jwt, qo_access_token, qo_session_id, qo_refresh_token)
Console — декодирование Base64:
Network — все реальные запросы к httpbin.org (видно заголовки Authorization, X-QO-Session-ID, X-API-Key)
Application → Storage — localStorage и Cookies (qo_jwt, qo_access_token, qo_session_id, qo_refresh_token)
Console — декодирование Base64:
atob("...")
Session Token Сессионный токен
Сервер создаёт уникальный session_id и хранит его в своей БД. Клиент получает его в Cookie — и отправляет обратно с каждым запросом.
1. Идентификация
2. Аутентификация
3. Авторизация
admin / admin123
🛡 Администратор
ivan / pass123
👨🎓 Студент
ivan / wrong
❌ Неверный пароль
Cookie в браузере
// Войдите, чтобы увидеть session_id
Запрос к API (каждый)
// После входа каждый запрос несёт Cookie автоматически
⚠ Почему не Cookie в Network? Браузер запрещает устанавливать заголовок
Cookie через JS (fetch/XHR) из соображений безопасности — это делает только сам браузер. Поэтому в реальный запрос идёт X-QO-Session-ID — чтобы показать идею. Сам cookie qo_session_id реально хранится в Application → Cookies.JWT JSON Web Token
Формат Header.Payload.Signature. Сервер не хранит токен — вся информация закодирована внутри. Хранится в localStorage, передаётся в заголовке Authorization.
1. Идентификация
2. Аутентификация
3. Авторизация
admin / admin123
🛡 Администратор
ivan / pass123
👨🎓 Студент
mentor / mentor456
👩🏫 Ментор
JWT токен H.P.S
// После входа здесь появится токен
Authorization заголовок
Authorization: Bearer ...
Декодированный токен
● HEADER (красный)
// войдите для декодирования
● PAYLOAD (жёлтый)
// войдите для декодирования
● SIGNATURE (синий) — серверная подпись, не декодируется без секретного ключа
HMACSHA256(base64url(header) + "." + base64url(payload), SECRET_KEY)
Access + Refresh Пара токенов
Access Token живёт 30 секунд в этом демо (в реальности 15–30 мин). Когда истекает — Refresh Token тихо получает новый.
admin / admin123
🛡 Администратор
ivan / pass123
👨🎓 Студент
Access Token localStorage
// После входа
Refresh Token Cookie
// После входа
API Key Ключ API
Статичный ключ без срока жизни. Нет входа в систему — только ключ. Передаётся в заголовке или URL-параметре.
Как работает: клиент получает API Key один раз (например, в личном кабинете сервиса) и хранит его. Идентификация и аутентификация — по ключу. Нет логина, нет сессии.
HTTP запрос
Сравнение способов и безопасность
# ✅ X-API-Key заголовок (рекомендуется)
GET /v1/courses
X-API-Key: sk_live_qo_1234567890abcdef
→ Не виден в URL-логах и истории браузера
# ⚠️ URL-параметр (не рекомендуется)
GET /v1/courses?api_key=sk_live_qo_1234567890abcdef
→ Ключ виден в адресной строке, логах сервера, Referer-заголовках
# ✅ Authorization заголовок
GET /v1/courses
Authorization: ApiKey sk_live_qo_1234567890abcdef
Basic Auth Базовая авторизация
Логин и пароль кодируются в Base64 и передаются в заголовке Authorization: Basic ... при каждом запросе.
⚠️ Важно: Base64 — это кодирование, не шифрование. Любой может декодировать его обратно за секунду. Basic Auth безопасен только поверх HTTPS.
ivan:pass123
aXZhbjpwYXNzMTIz
HTTP запрос с Basic Auth
Декодирование в DevTools Console
Попробуй сам в консоли браузера (F12 → Console)
// Кодирование:
btoa("ivan:pass123") // → "aXZhbjpwYXNzMTIz"
// Декодирование — это может сделать ЛЮБОЙ!
atob("aXZhbjpwYXNzMTIz") // → "ivan:pass123"
// Именно поэтому Basic Auth нужен только поверх HTTPS
OAuth 2.0 Authorization Code Flow
Что происходит шаг за шагом, когда пользователь нажимает «Войти через Google». Нажимай «Следующий шаг» для прохождения потока.
👤
Пользователь
🖥️
Приложение (quickoffer.ru)
🔐
Auth Server (Google)
📦
Resource Server (Google API)
Шаг 0 / 8
Нажмите «Следующий шаг» для начала
// Здесь будет показан HTTP-запрос или ответ для каждого шага
💡 Ключевая идея OAuth: приложение quickoffer.ru никогда не видит ваш пароль от Google.
Google сам проверяет личность и выдаёт приложению только токен доступа с ограниченными правами.