Как защитить REST API (аутентификация, авторизация, транспорт)?

Question

IT Interview Practice · Accepted Answer

Защита REST API означает ответ на три вопроса при каждом запросе: **кто ты** (аутентификация), **что тебе разрешено делать** (авторизация) и **приватен ли канал** (транспорт). Поскольку REST **stateless**, учётные данные должны путешествовать с каждым запросом, а не жить в серверной сессии.

## Транспорт: всегда HTTPS

Всё нижеследующее предполагает **TLS/HTTPS**. Без него токены и API-ключи идут открытым текстом и могут быть перехвачены. Это не обсуждается — bearer-токен по HTTP это утёкший токен.

## Варианты аутентификации

**API keys** — статический секрет в заголовке. Просто; хорошо для server-to-server и идентификации *приложения*, а не пользователя. Сами по себе слабы (нет срока, нет scope), если не дополнены чем-то ещё.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — стандарт для **делегированного** доступа («пусть App X читает мои данные без моего пароля»). Приложение получает **access token** через flow (например, Authorization Code) и отправляет его как bearer-токен. Так работают «Sign in with Google» и сторонние интеграции.

**JWT (JSON Web Token)** — распространённый *формат* токенов: подписанный самодостаточный токен, несущий claims (user id, роли, срок). Сервер проверяет подпись — без обращения к базе данных, что подходит stateless REST.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Авторизация: scopes и roles

Аутентификация доказывает личность; **авторизация** решает доступ. Токены несут **scopes** (`orders:read`, `orders:write`) или роли; сервер проверяет их для каждого endpoint и возвращает `403 Forbidden`, когда их недостаточно (в отличие от `401` при отсутствующей/неверной аутентификации).

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## Прочее необходимое

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## Почему это важно

Безопасность — это место, где маленькая ошибка становится взломом, поэтому интервьюеры используют это, чтобы понять, рассуждаете ли вы о ней структурно, а не декламируете модные слова. Сигнал, который они ищут, — что вы **разделяете три слоя** — транспорт (HTTPS, всегда), аутентификация (доказательство личности, без состояния, через bearer-токены/JWT/OAuth) и авторизация (scopes и least privilege) — и не смешиваете их, например, корректно используя `401` для «не аутентифицирован» против `403` для «аутентифицирован, но не разрешено». Сильные ответы показывают осознание практических компромиссов: JWT удобны и stateless, но их трудно отозвать до истечения (отсюда короткие сроки жизни плюс refresh-токены), API-ключи идентифицируют приложения, а не пользователей, и OAuth существует именно для того, чтобы пользователи не отдавали свой пароль третьим сторонам. Привязка к statelessness REST — учётные данные в каждом запросе, без серверной сессии — показывает, что вы понимаете, *почему* безопасность API выглядит так, как выглядит.

Транспорт: всегда HTTPS

Варианты аутентификации

Авторизация: scopes и roles

Прочее необходимое

Почему это важно

Похожие вопросы