Как настроить авторизацию в приложении: OTP, сессии, токены

Игра вроде Змейки готова — и теперь хочется, чтобы у каждого игрока был свой аккаунт: сохранялся рекорд, открывался магазин скинов, работала таблица лидеров. Значит, нужно научить приложение узнавать пользователя. Классический путь — попросить придумать пароль. Но пароли легко забыть, ещё легче украсть, а хранить их безопасно — отдельная наука. В курсе skillmake для входа используется код на почту: ты вводишь email, получаешь шестизначный код, вводишь его — и ты внутри. Разберёмся, как работает такая авторизация, что происходит с сессией, зачем нужны cookie и токены и почему от паролей можно отказаться.

Зачем отказываться от паролей в простом приложении

Пароль кажется простым: придумал, запомнил, ввёл. На деле он создаёт несколько проблем.

• Пользователи выбирают слабые пароли. 123456, qwerty, дни рождения — всё это легко подбирается.
• Пароли повторяются. Если один сервис утёк, злоумышленники пробуют те же данные на других.
• Хранить пароли сложно. Даже захешированный пароль требует соли, медленных алгоритмов и постоянной бдительности. Ошибка в одной строчке — и база данных раскрыта.
• Пароль нужно восстанавливать. Забыл — жди письма, кликай ссылку, придумывай новый.

В небольшом проекте, где ты и сам разрабатываешь бэкенд, проще и безопаснее переложить проверку личности на почту или на внешний сервис вроде Google. Ты не хранишь секрет пользователя у себя — значит, не можешь его потерять.

OTP: одноразовый пароль на почту

OTP расшифровывается как One-Time Password, то есть «одноразовый пароль». Это код, который действует короткое время и подходит только для одного входа.

В сценарии из курса работает так:

1. Пользователь вводит свой email в форму входа.
2. Приложение просит Supabase отправить письмо с кодом.
3. На почту приходит шестизначный код, обычно с коротким сроком жизни — например, 10 минут.
4. Пользователь вводит код в приложение.
5. Supabase проверяет код: если он правильный и не просроченный, считает, что человек действительно владеет почтой.

Почта здесь выступает каналом проверки. Код — это не пароль, его нельзя использовать дважды и нет смысла запоминать. Если кто-то перехватит старый код, он уже не сработает.

Представь это как вход в подъезд по звонку в concierge: ты говоришь свой адрес, concierge звонит тебе на мобильный, ты называешь код из СМС — дверь открывается. Код работает один раз, и concierge не хранит у себя твои ключи.

Что такое сессия

После успешной проверки кода приложению нужно помнить, что ты уже вошёл. Иначе при каждом клике пришлось бы вводить email и код заново.

Сессия — это временное состояние «пользователь авторизован». Сервер создаёт запись о том, что вот этот конкретный посетитель успешно прошёл проверку, и даёт ей уникальный номер — идентификатор сессии.

У сессии есть срок жизни. Например, две недели. Пока сессия активна, приложение считает тебя своим и показывает персональные данные: твой рекорд в Змейке, купленные скины, место в таблице лидеров. Когда срок истекает, сессия удаляется, и пользователю снова нужно войти.

Сессии хранятся на сервере. Это удобно, потому что сервер может в любой момент отозвать сессию: например, если увидит подозрительную активность или если пользователь нажал «Выйти на всех устройствах».

Cookie: как браузер запоминает сессию

Браузер и сервер общаются по HTTP — протоколу, в котором каждый запрос по сути независимый. Без дополнительных механизмов сервер не отличит новый запрос от продолжения старого разговора.

Cookie — это маленький фрагмент данных, который сервер просит браузер сохранить и присылать с каждым следующим запросом. В случае авторизации в cookie обычно хранится идентификатор сессии.

Когда ты вошёл по коду, сервер говорит браузеру:

Важные свойства cookie:

• HttpOnly — cookie недоступна JavaScript на странице. Это защищает от XSS-атак, когда злоумышленник пытается украсть данные через вредоносный скрипт.
• Secure — cookie передаётся только по HTTPS, то есть в зашифрованном виде.
• SameSite — ограничивает, когда cookie отправляется с запросами с других сайтов. Это защита от CSRF-атак.
• Expires / Max-Age — время жизни cookie. Обычно совпадает со сроком сессии.

Cookie не содержат пароль и не дают прямого доступа к данным. Это просто «пропуск», по которому сервер находит активную сессию.

Токен: когда приложение общается с API

Cookie хороши для классических веб-страниц, но современные приложения часто общаются с сервером через API. Здесь удобнее использовать токен.

Токен — это подписанная строка, которая подтверждает личность пользователя. Самый распространённый формат — JWT (JSON Web Token). Он состоит из трёх частей:

1. Заголовок — информация о типе токена и алгоритме подписи.
2. Полезная нагрузка — данные о пользователе, например ID и срок действия.
3. Подпись — криптографическая проверка, что токен не подделали.

Токен выдаётся после входа. Приложение сохраняет его в памяти или в безопасном хранилище и прикрепляет к каждому запросу к API, обычно в заголовке Authorization: Bearer <токен>.

Сервер, получив токен, проверяет подпись и срок действия. Если всё в порядке — выполняет запрос. Если токен просрочен или подделан — отказывает.

Supabase использует собственную схему токенов для доступа к базе данных и API. Когда ты входишь через OTP, Supabase возвращает токены, и твой код использует их для запросов к таблицам — например, чтобы записать новый рекорд именно для этого пользователя.

Как это работает вместе на примере Змейки

Представь, что в Змейке появилась таблица лидеров. Игрок хочет, чтобы его результат сохранялся под именем, а не терялся при закрытии вкладки.

1. Игрок открывает игру и нажимает «Войти».
2. Вводит email, нажимает «Отправить код».
3. Supabase отправляет на этот адрес одноразовый код.
4. Игрок вводит код, Supabase проверяет его.
5. После успеха Supabase создаёт сессию и возвращает токены.
6. Браузер сохраняет идентификатор сессии в cookie.
7. Приложение сохраняет токен для запросов к API.
8. Когда игрок бьёт рекорд, приложение отправляет результат в Supabase с токеном.
9. Supabase видит по токену, кто именно установил рекорд, и записывает его в таблицу лидеров.
10. При следующем открытии игры браузер пришлёт cookie, Supabase найдёт сессию, и игрок снова окажется внутри — до тех пор, пока сессия не истечёт.

Пароль при этом нигде не фигурирует. Ты не хранишь его в базе, не проверяешь сложность, не восстанавливаешь. Вся ответственность за подтверждение личности лежит на почтовом сервисе и на механизме OTP, который предоставляет Supabase.

Практический блок: как применить и проверить

Если ты собираешь авторизацию в своём проекте, пройди по этому чек-листу:

• Выбери провайдера аутентификации. Supabase — удобный вариант для проектов курса: в нём уже есть OTP, сессии, токены и защита cookie. Официальная документация: supabase.com/docs/guides/auth.
• Настрой отправку писем. В Supabase это делается в разделе Auth → Email Templates. Письмо можно отредактировать под свой проект.
• Используй готовый клиент. Supabase предоставляет JavaScript-библиотеку, которая берёт на себя работу с cookie, токенами и обновлением сессии.
• Проверь защиту cookie. В настройках сессии должны быть включены HttpOnly и Secure для продакшена.
• Задай разумный срок жизни сессии. Для игры подойдёт несколько дней или недель. Для банковского приложения — минуты.
• Проверь выход. Кнопка «Выйти» должна не просто стирать данные на клиенте, но и инвалидировать сессию на сервере.
• Тестируй в режиме инкогнито. Открой игру, войди, закрой вкладку, открой снова — ты должен оставаться авторизованным. Затем нажми «Выйти» и убедись, что доступ к личным данным пропал.

Частые ошибки новичков

Ошибка 1. Хранить пароли в localStorage

localStorage доступен любому JavaScript на странице. Если злоумышленник внедрит вредоносный код, он легко заберёт токен или пароль. Для сессионных данных лучше использовать cookie с флагом HttpOnly.

Ошибка 2. Не проверять срок действия токена

Токены не вечны. Если приложение не обновляет токен и не обрабатывает ошибку «истёк», пользователь внезапно увидит страницу, на которой ничего не работает.

Ошибка 3. Доверять данным на клиенте

Нельзя решать на стороне браузера, что пользователь может видеть чужой рекорд. Правила доступа должны проверяться на сервере — например, через Row Level Security в Supabase.

Ошибка 4. Забывать про кнопку «Выйти»

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

Заключение + чек-лист

Авторизация без пароля через OTP — простой и безопасный способ узнавать пользователей в небольших приложениях. Вместо того чтобы придумывать и хранить секреты, ты передаёшь проверку личности почте и внешнему сервису. Сессия запоминает, что человек вошёл, cookie помогает браузеру её передать, а токен позволяет безопасно обращаться к API.

Для проекта вроде Змейки, где нужны аккаунты и таблица лидеров, этот подход идеален: он работает «из коробки» в Supabase, не требует ручного управления паролями и понятен новичкам.

Чек-лист «Авторизация настроена правильно»

• Вход реализован через OTP или внешнего провайдера, пароли не хранятся в проекте.
• Сессия имеет разумный срок жизни и отзывается при выходе.
• Cookie настроены с флагами HttpOnly, Secure и SameSite.
• Токены обновляются автоматически и проверяются на сервере.
• Правила доступа к данным настроены на бэкенде, а не только на клиенте.
• Проверено: после закрытия вкладки пользователь остаётся авторизованным.
• Проверено: после нажатия «Выйти» доступ к личным данным пропадает.
• В письмо с кодом добавлены понятный текст и срок действия кода.