Перейти на PRO

Какие основные виды авторизации в веб-приложениях?

Тип вопроса: Веб-тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Основные механизмы авторизации для веба:

  1. Cookie-based (Session-based) Authentication

    • Как работает: После проверки логина/пароля сервер создает запись сессии (например, в БД или Redis) и отправляет её уникальный ID клиенту в cookie.
    • Пример установки cookie: 
      HTTP/1.1 200 OK
Set-Cookie: session_id=s3cr3tS3ss10nId; HttpOnly; Secure; SameSite=Lax
    • Почему это важно: HttpOnly защищает от кражи через XSS, Secure гарантирует передачу только по HTTPS, SameSite помогает против CSRF-атак.

  2. Token-based Authentication (часто с JWT)

    • Как работает: Токен (обычно JWT) хранится на клиенте (в localStorage или sessionStorage) и отправляется в заголовке Authorization.
    • Пример запроса с JWT: 
      fetch('/api/data', {
  headers: {
    'Authorization': 'Bearer ' + localStorage.getItem('jwt_token')
  }
});
    • Почему это важно: Позволяет строить SPA (Single Page Applications) и мобильные клиенты, независимые от серверных сессий. Однако требует защиты от XSS для безопасного хранения токена.

  3. OAuth 2.0 / OpenID Connect (OIDC)

    • Как работает: Пользователь перенаправляется на страницу провайдера (Google, GitHub), где дает согласие. После успеха провайдер перенаправляет обратно с authorization_code или сразу access_token.
    • Почему это важно: Пользователям не нужно создавать новый пароль. Приложение получает ограниченный доступ к данным пользователя на стороннем сервисе.

  4. Basic Authentication

    • Как работает: Браузер отобрачает стандартное диалоговое окно для ввода логина и пароля, которые затем передаются в каждом запросе.
    • Почему это важно: Крайне редко используется для пользовательских веб-приложений из-за низкой безопасности и плохого UX. Может применяться для защиты административных или внутренних панелей.

Ключевые аспекты безопасности для веба:

  • Всегда использовать HTTPS.
  • Для cookie: флаги HttpOnly, Secure, SameSite.
  • Для токенов в JS: осознавать риски XSS и использовать короткое время жизни токена (JWT exp claim) с механизмом обновления.
  • Защита от CSRF (например, с помощью токенов CSRF или политики SameSite для cookie).
  • Защита от XSS, так как она может привести к краже сессионных cookie или токенов.

Ответ 18+ 🔞

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

1. Сессии через куки (Старая добрая классика) Представь: пользователь ввёл логин-пароль, сервер их проверил и думает: «Окей, чувак, ты свой». Но сервер — он же не слон, чтобы помнить каждого. Он создаёт в своей памяти (или в БД, или в Redis) запись — сессию. А клиенту в ответ суёт бумажку с номерком этой сессии. Эта бумажка — кука.

HTTP/1.1 200 OK
Set-Cookie: session_id=s3cr3tS3ss10nId; HttpOnly; Secure; SameSite=Lax

Вот эти флаги — они не просто так, это бронежилет для куки. HttpOnly — чтобы какой-нибудь ебучий XSS-скрипт не утянул её, Secure — летает только по HTTPS, SameSite — защита от CSRF, чтобы с других сайтов не прилетали левые запросы от твоего имени. Просто, но надёжно, как топор.

2. Токены (JWT и прочая современная хуета) Тут философия другая. Сервер не хранит хуя. Всё состояние зашито в сам токен (обычно JWT). Клиент получает эту зашифрованную строку и таскает её с собой в каждом запросе, обычно в заголовке.

fetch('/api/data', {
  headers: {
    'Authorization': 'Bearer ' + localStorage.getItem('jwt_token')
  }
});

Удобно для SPA и мобилок — серверу похуй, он просто проверяет подпись токена. Но есть нюанс, ёпта: токен обычно лежит в localStorage. А это значит, что если на сайте найдётся XSS-дыра — токен уплывёт, и злоумышленник сможет им пользоваться, пока срок жизни не истечёт. Поэтому короткий exp и механизм refresh-токенов — твои лучшие друзья.

3. OAuth 2.0 / OpenID Connect (Давайте жить дружно) Это когда твоё приложение такое: «Э, пользователь, не хочешь ли ты войти через Гугл?». Пользователь идёт к Гуглу, тот спрашивает: «Ты уверен, что хочешь дать доступ этому подозрительному сайту?». Пользователь говорит «Да», и Гугл выдаёт тебе токен доступа к его данным (в рамках разрешённого). Пользователь счастлив — пароль новый придумывать не надо. Ты счастлив — часть логики аутентификации на тебе не висит. Все в плюсе, кроме параноиков, которые никому не доверяют.

4. Basic Authentication (Каменный век) Браузер показывает то самое стандартное окошко «Введите логин и пароль». Эти креденшиалы потом кодируются в base64 и пихаются в заголовок каждого запроса. Выглядит страшно и небезопасно. Для публичных веб-приложений — полный пиздец и моветон. Может сгодиться разве что для какой-нибудь внутренней админки, закрытой от всего интернета.

А теперь про безопасность, без которой всё это — говно:

  • HTTPS — обязательно. Без него все твои куки и токены летят по сети как голые по проспекту.
  • Для кук: HttpOnly, Secure, SameSite. Выучи как «Отче наш».
  • Для токенов в JS: помни про XSS. Короткий срок жизни (exp) + refresh-токен, хранимый максимально безопасно.
  • CSRF: либо используй SameSite=Lax/Strict для кук, либо генерируй CSRF-токены.
  • XSS: если его не победить, то всё остальное — ебаная профанация. Любой скрипт сможет украсть сессию или токен. Санитайзация, экранирование, Content Security Policy (CSP) — твои главные инструменты.

Вот и вся магия. Ничего сверхъестественного, но если накосячить в основах — будет очень больно и стыдно.

© ХакСобесов, 2026
support@hacksobesov.com