Authorization

HTTP Authorization Header: Полное руководство по авторизации в REST API

📚 24 вопросовПройти тест →
Лекция

HTTP Authorization Header: Полное руководство по авторизации в REST API

Authorization

HTTP Authorization Header: Полное руководство по авторизации в REST API

Введение: пропуск на объект 🪪

Authorization header — это «пропуск» в HTTP‑запросе: мы показываем его и получаем доступ.
💡 Совет: пароль не должен уходить в сторонние приложения.
✅ Вывод: стандартный заголовок делает авторизацию предсказуемой.

Проблема → решение

Проблема: токены утекают, статусы путаются, доступ реализуют «как получится».
Решение: единый формат Authorization, правильные схемы, корректные 401/403.
✅ Вывод: единые правила = меньше ошибок.

Чем помогает и как работает

Authorization header помогает:
  • передавать доступ стандартно;
  • не светить пароль и не таскать токены в URL;
  • безопасно работать с короткими access token.
Как это работает (по шагам):
  1. Система выдаёт постоянный ключ (API Key или refresh token) после регистрации/логина.
  2. Клиент получает временный access token на короткий срок (минуты/часы).
  3. Каждый запрос к API содержит Authorization: Bearer <access_token>.
  4. Access token истёк — клиент обновляет его через refresh token.
  5. Если токена нет или прав мало — сервер отвечает 401/403.

✅ Вывод: Authorization header — центральная точка контроля доступа.

Ключевые термины (простыми словами)

  • Authorization Header — место, где передаём доступ.
  • Scheme — тип авторизации (Bearer, Basic, ApiKey).
  • Bearer Token — access token.
  • Basic Auth — логин:пароль в заголовке.
  • API Key — ключ приложения.
  • WWW-Authenticate — подсказка клиенту.
  • 401/403 — статусы отказа.

Самое важное (must‑know)

  • Формат: Authorization: <scheme> <credentials>.
  • 401 возвращаем с WWW-Authenticate.
  • 403 — прав недостаточно.
  • Токен нельзя передавать в URL.
  • Basic только через HTTPS.
  • В логах Authorization маскируем.

1. Authorization Header — формат

Назначение: передать доступ стандартно.
Простыми словами: кладём ключ в специальный заголовок.
Аналогия: пропуск на входе.
Пример:
GET /orders/42Authorization: Bearer eyJhbGciOi...
🔎 Как это происходит на практике:
  1. Клиент добавляет Authorization.
  2. Сервер извлекает схему и данные.
  3. Ответ — 200, 401 или 403.
Характеристики:
  • ✅ единый формат;
  • ✅ схема + данные;
  • ✅ подходит для любых клиентов.
Когда использовать: все защищённые запросы.
✅ Вывод: Authorization — главный контейнер доступа.

2. Bearer Token — стандарт OAuth

Назначение: передать access token.
Простыми словами: временный пропуск.
Аналогия: браслет на мероприятии.
Пример:
Authorization: Bearer <token>
🔎 Как это происходит на практике:
  1. Клиент получает токен.
  2. Отправляет Bearer в заголовке.
  3. API проверяет токен и scope.
Характеристики:
  • ✅ токен секретный;
  • ✅ короткий TTL;
  • ✅ может быть JWT.
Когда использовать: OAuth 2.0 клиенты.
✅ Вывод: Bearer — основной вариант.

3. Basic Auth — логин и пароль

Назначение: быстро авторизовать внутренние сервисы.
Простыми словами: пароль в Base64.
Аналогия: сказать пароль вслух.
Пример:
Authorization: Basic dXNlcjpwYXNz
🔎 Как это происходит на практике:
  1. Клиент кодирует user:pass.
  2. Отправляет в Authorization.
  3. Сервер декодирует и проверяет.
Характеристики:
  • ✅ Base64 не шифрует;
  • ✅ только HTTPS;
  • ✅ только internal.
Когда использовать: сервис‑to‑сервис.
✅ Вывод: Basic прост, но рискован.

4. API Key — доступ для приложений

Назначение: идентифицировать сервис без пользователя.
Простыми словами: ключ для приложения.
Аналогия: пропуск подрядчика.
Пример:
Authorization: ApiKey a1b2c3
🔎 Как это происходит на практике:
  1. Сервис получает ключ.
  2. Передаёт его в заголовке.
  3. API проверяет и лимитирует.
Характеристики:
  • ✅ ключ можно отозвать;
  • ✅ подходит для server‑to‑server.
Когда использовать: публичные API.
✅ Вывод: ApiKey удобен для машин.

5. 401 vs 403

Назначение: правильно объяснить отказ.
Простыми словами: 401 — «не показал пропуск», 403 — «пропуск есть, но нельзя».
Аналогия: охранник у двери.
Пример:
HTTP/1.1 401 UnauthorizedWWW-Authenticate: Bearer realm="api"
🔎 Как это происходит на практике:
  1. Нет токена → 401.
  2. Нет прав → 403.
  3. Клиент понимает причину.
Характеристики:
  • ✅ 401 с WWW-Authenticate;
  • ✅ 403 без него.
Когда использовать: все защищённые эндпоинты.
✅ Вывод: статусы — часть UX.

6. Хранение токена

Назначение: защитить токен от утечек.
Простыми словами: ключи не кладём на витрину.
Аналогия: держим пропуск в кармане.
Пример:
Set-Cookie: access_token=...; HttpOnly; Secure; SameSite=Lax
🔎 Как это происходит на практике:
  1. Сервер кладёт токен в HttpOnly cookie.
  2. Браузер отправляет его сам.
  3. JS не может украсть токен.
Характеристики:
  • ✅ не передавать в URL;
  • ✅ HttpOnly + Secure + SameSite;
  • ✅ маскировать в логах.
Когда использовать: браузерные клиенты.
✅ Вывод: хранение критично.

Сравнение: схемы

СхемаПлюсыМинусы
Bearerстандарт OAuthнужно защищать токен
BasicпростотаBase64 не защищает
ApiKeyудобно для сервисовнет пользователя

Сравнение: 401 vs 403

КодКогда
401нет/неверный токен
403прав недостаточно

Типичные ошибки

Ошибка 1: Токен в URL

❌ Неправильно: /api?token=....
✅ Правильно: Authorization: Bearer ....
Почему: URL попадает в логи.

Ошибка 2: Basic без HTTPS

❌ Неправильно: Basic по HTTP.
✅ Правильно: только HTTPS.
Почему: Base64 не защита.

Ошибка 3: localStorage

❌ Неправильно: хранить токен в localStorage.
✅ Правильно: HttpOnly cookie.
Почему: XSS.

Ошибка 4: 403 вместо 401

❌ Неправильно: 403 когда токена нет.
✅ Правильно: 401 + WWW-Authenticate.
Почему: клиенту нужна подсказка.

Ошибка 5: Логи с токенами

❌ Неправильно: логировать Authorization.
✅ Правильно: маскировать.
Почему: логи — источник утечек.

Best Practices

  • Всегда HTTPS.
  • Bearer только в Authorization.
  • 401 с WWW-Authenticate.
  • Короткий access token + защищённый refresh.
  • Маскировать токены в логах.
  • Документировать схему.

Часто спрашивают на собеседованиях

  • Чем Bearer отличается от Basic?
  • Почему 401 возвращает WWW-Authenticate?
  • Почему нельзя токен в URL?
  • Что безопаснее: localStorage или HttpOnly?
  • JWT шифруется или подписывается?
✅ Вывод: лекция закрывает базовые интервью‑вопросы.

Заключение

Authorization header — стандартный и безопасный способ авторизации.
✅ Вывод: соблюдайте формат и правила хранения.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Authorization header»

Пройти тест →