Аутентификация и авторизация: OAuth2, JWT и scopes простыми словами

Однажды на ревью спеки я спросил: «А что значит „пользователь авторизован“ в этом сценарии — он вошёл или ему можно сюда?» Повисла пауза. Выяснилось, что бэкендер имел в виду «вошёл в систему», а аналитик — «имеет право видеть этот раздел». В коде это два разных места, две разные ошибки (401 и 403), и из-за смешения этих слов сценарий был дырявым. С тех пор я развожу эти два понятия в спеке жёстко.

Аутентификация и авторизация: «кто ты» против «что можно»

Самая частая путаница в этой теме — и стоит она дорого, потому что слова похожи, а смысл разный.

Аутентификация (authentication) — проверка, кто вы. Вы показываете удостоверение, система убеждается, что вы — это вы. Логин с паролем, код из СМС, токен — всё это про аутентификацию. Если не прошли — сервер отвечает 401 Unauthorized (несмотря на название, это про «не представился»).

Авторизация (authorization) — проверка, что вам разрешено. Вы уже известны системе, вопрос в правах: можете ли вы открыть этот раздел, удалить этот заказ, увидеть чужие данные. Если прав нет — сервер отвечает 403 Forbidden («ты известен, но сюда нельзя»). Коды ответов разбираются подробнее в записи про REST API.

OAuth2 на пальцах: доступ без пароля

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

В OAuth2 четыре роли — их полезно знать наизусть, потому что в любой спеке на интеграцию вы будете расставлять, кто здесь кто:

• Владелец ресурса — вы, пользователь, чьи данные защищены.
• Клиент — приложение, которое хочет доступ (тот самый планировщик).
• Сервер авторизации — тот, кто проверяет вас и выдаёт токены (например, аккаунты Google).
• Сервер ресурсов — где лежат данные и кто отдаёт их по токену (API календаря).

Ключевая идея: вместо пароля клиент получает access token — временный пропуск с ограниченными правами. Токен можно отозвать, он протухает сам, и он не открывает доступ ни к чему сверх разрешённого. Пароль остаётся только между вами и Google.

Типичный сценарий: authorization code flow

sequenceDiagram
  participant U as Пользователь
  participant C as Клиент (приложение)
  participant A as Сервер авторизации
  participant R as Сервер ресурсов (API)
  U->>C: «Подключить мой календарь»
  C->>A: редирект: дай доступ к календарю (scope)
  A->>U: страница входа + «разрешить приложению?»
  U->>A: ввёл пароль, нажал «разрешить»
  A-->>C: код авторизации (одноразовый)
  C->>A: меняю код на access token (+ секрет клиента)
  A-->>C: access token (scope: calendar.read)
  C->>R: запрос к API + access token
  R-->>C: данные календаря

Схема описывает самый распространённый сценарий OAuth2 — authorization code flow. Пользователь нажимает «подключить календарь» в приложении. Приложение не спрашивает пароль само, а перенаправляет пользователя на сервер авторизации (Google) с указанием, какой доступ нужен (scope). Google показывает свою страницу входа и спрашивает «разрешить этому приложению читать календарь?». Пользователь вводит пароль на стороне Google и соглашается — приложение пароль не видит. В ответ приложение получает одноразовый код авторизации и тут же меняет его на access token, подтверждая при этом и свою личность секретом клиента. Дальше приложение ходит в API календаря, прикладывая токен, и получает данные. Пароль за всю цепочку ни разу не попал в чужие руки.

JWT: самодостаточный токен

Токен бывает разный. Один из самых популярных форматов — JWT (JSON Web Token). Это строка из трёх частей, разделённых точками: header.payload.signature.

• Header — что это за токен и каким алгоритмом подписан.
• Payload — полезная нагрузка: кто пользователь, его id, права, когда токен истекает. Это обычный JSON, закодированный в строку (не зашифрованный — кто угодно может прочитать, поэтому пароли туда не кладут).
• Signature — подпись, которой сервер заверяет, что содержимое не подменили.

Главная фишка JWT — он самодостаточный. Внутри уже лежит всё, что нужно: кто пользователь и что ему можно. Сервер проверяет подпись и доверяет содержимому, не заглядывая в базу при каждом запросе. Это снимает нагрузку и позволяет не хранить состояние сессии на сервере — удобно, когда серверов много.

Scopes и ролевая модель

Scope — это конкретное разрешение, выданное токену. Не «полный доступ», а перечень: calendar.read (только читать календарь), orders.write (создавать заказы). Когда приложение запрашивает доступ, оно перечисляет нужные scopes, пользователь видит их на экране согласия («приложение хочет: читать ваш календарь») и соглашается осознанно. Это и есть авторизация в действии: токен носит с собой ровно те права, что ему дали.

Scopes часто связывают с ролевой моделью (RBAC): пользователю назначают роль (например, «менеджер»), а роль уже разворачивается в набор прав. В требованиях полезно описывать именно матрицу «роль → что можно», а scopes — это техническая форма, в которой эта матрица доезжает до API.

Частые вопросы

Чем аутентификация отличается от авторизации?

Аутентификация отвечает на вопрос «кто ты» — это проверка личности (логин, пароль, токен, код из СМС). Авторизация отвечает «что тебе можно» — это проверка прав на конкретное действие или данные. Сначала система убеждается, что вы — это вы (аутентификация), потом решает, куда вас пускать (авторизация). В HTTP им соответствуют коды 401 (не представился) и 403 (представился, но нельзя).

Что такое JWT простыми словами?

JWT (JSON Web Token) — это формат токена в виде строки из трёх частей через точку: header.payload.signature. В payload зашита информация о пользователе и его правах, signature — подпись сервера, подтверждающая, что данные не подменили. JWT самодостаточен: сервер проверяет подпись и доверяет содержимому, не заглядывая в базу. Минус — такой токен трудно отозвать досрочно, поэтому его делают короткоживущим.

Что такое scope в OAuth2?

Scope — это конкретное разрешение, которое получает токен: например, calendar.read (только читать календарь) или orders.write (создавать заказы). Приложение запрашивает нужные scopes, пользователь видит их на экране согласия и осознанно разрешает. Scopes ограничивают, что именно может делать токен, и часто связаны с ролевой моделью, где роль пользователя разворачивается в набор прав.