Авторизация: что это, чем отличается от аутентификации и как проводится

Авторизация — это проверка того, какие действия разрешены пользователю и к каким данным у него есть доступ. Она отвечает на вопрос «что тебе можно», а не «кто ты». Проверка личности — это отдельный шаг, аутентификация, и путать эти два понятия не стоит: именно на их различии держится вся тема.

Ниже разбираю по порядку: чем идентификация, аутентификация и авторизация отличаются друг от друга, как выглядит обычный вход на сайт, зачем нужны токены и сессии, как работает вход через сторонний сервис (OAuth), что лежит внутри токена JWT и как права раздают по ролям. Материал для новичка, но доводит тему до технического уровня, а не останавливается на «нажмите кнопку Войти».

Идентификация, аутентификация, авторизация: в чем разница

Эти три слова часто используют как синонимы, хотя они описывают разные шаги одного процесса. Разведу их на сквозном примере — вход в почту.

• Идентификация — вы сообщаете системе, кем себя считаете. Это ввод логина, e-mail или номера телефона. Система по нему находит вашу запись, но пока не верит, что это действительно вы.
• Аутентификация — проверка подлинности. Вы доказываете, что запись ваша: вводите пароль, код из SMS, прикладываете отпечаток пальца. Отвечает на вопрос «кто ты».
• Авторизация — проверка прав. Система решает, что именно вам разрешено: читать письма, менять настройки, удалять чужие сообщения. Отвечает на вопрос «что тебе можно».

Цепочка всегда идет в этом порядке: сначала система понимает, за кого вы себя выдаете, потом убеждается, что это правда, и только затем выдает права. Можно быть аутентифицированным (система знает, что это вы), но не авторизованным на конкретное действие — например, обычный пользователь вошел в свой аккаунт, но не может открыть админ-панель.

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

Как проходит обычный вход на сайт

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

1. Вы открываете страницу входа и вводите логин (идентификация).
2. Вводите пароль. Сервер сравнивает его не с сохраненным паролем напрямую, а с его хешем — необратимым отпечатком (аутентификация). Хранить пароли в открытом виде — грубая ошибка безопасности.
3. Если проверка прошла, сервер создает сессию и выдает браузеру признак входа — чаще всего cookie. Дальше при каждом запросе система по этому признаку понимает, кто вы, и проверяет права на конкретное действие (авторизация).

Именно поэтому после входа не нужно вводить пароль на каждой странице: система один раз проверила подлинность, а дальше на каждом шаге сверяет только права.

Кроме пароля личность подтверждают и другими способами: код из SMS или письма, одноразовый пароль из приложения-аутентификатора, вход по QR-коду, биометрия. При двухфакторной аутентификации пароль дополняют вторым независимым фактором, и утечка одного пароля уже не открывает доступ.

Токены и сессии: чем система помнит про вход

HTTP сам по себе не запоминает состояние: каждый запрос к серверу как будто первый. Чтобы не спрашивать пароль постоянно, применяют два подхода к тому, как хранить факт входа.

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

Токен на стороне клиента. Сервер выдает подписанный токен, который хранит сам клиент (браузер, приложение) и присылает с каждым запросом. Серверу не нужно держать запись о сессии — он лишь проверяет подпись токена. Это удобно, когда запросы обслуживают много серверов сразу.

На практике токенов обычно два. Access-токен — короткоживущий (минуты или часы), им подписывают рабочие запросы. Refresh-токен — долгоживущий, по нему выдают новый access-токен, когда старый истек, не спрашивая пароль заново. Короткий срок access-токена ограничивает ущерб, если он утечет.

OAuth 2.0: вход через другой сервис

Кнопки «Войти через Google» или «Войти через Яндекс» работают по протоколу OAuth 2.0 (RFC 6749). Его задача — дать стороннему приложению доступ к части ваших данных, не передавая ему ваш пароль.

Важно, что делает именно OAuth: это протокол авторизации (выдачи прав на доступ к ресурсам), а не проверки личности. Когда сайту нужно еще и узнать, кто вы, поверх OAuth используют надстройку OpenID Connect.

Упрощенно вход через OAuth выглядит так:

1. На стороннем сайте вы жмете «Войти через Google».
2. Вас перенаправляет на сам Google, где вы уже вошли или вводите пароль. Пароль видит только Google, стороннему сайту он не достается.
3. Google спрашивает, согласны ли вы дать сайту доступ к конкретным данным (например, к имени и e-mail).
4. После согласия сайт получает от Google токен и по нему обращается к разрешенным данным.

Ключевая выгода: пароль остается у поставщика (Google, Яндекс), а сайт получает ограниченный доступ, который вы в любой момент отзываете в настройках аккаунта.

На смену OAuth 2.0 готовится OAuth 2.1 — не новая технология, а сборка проверенных практик в одном документе: обязательный механизм защиты PKCE и отказ от небезопасных устаревших схем. На 2026 год это еще черновик IETF (редакция draft-15 от марта 2026), а рабочим стандартом остается OAuth 2.0.

JWT: что лежит внутри токена

Часто в роли токена выступает JWT (JSON Web Token, RFC 7519). Это строка из трех частей, разделенных точками: заголовок.данные.подпись. Первые две части — это обычный JSON, закодированный в base64url (это кодирование, а не шифрование: содержимое можно прочитать, но не подменить незаметно).

• Заголовок (header) — алгоритм подписи и тип токена.
• Данные (payload) — набор утверждений: кто пользователь, какая у него роль, когда токен истекает.
• Подпись (signature) — контрольная сумма первых двух частей, вычисленная с секретным ключом сервера. Если кто-то изменит данные, подпись перестанет сходиться.

Разберем токен на Python. Возьмем готовый JWT и раскодируем первые две части — подпись здесь не проверяем, только читаем содержимое:

import base64
import json

# JWT состоит из трех частей, разделенных точками
token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMDA1Iiwicm9sZSI6ImVkaXRvciJ9.c2lnbmF0dXJlX2J5dGVz"
header_b64, payload_b64, signature = token.split(".")

def decode(part):
    # base64url без выравнивания: добиваем '=' до длины, кратной 4
    part += "=" * (-len(part) % 4)
    return base64.urlsafe_b64decode(part)

print(json.loads(decode(header_b64)))
print(json.loads(decode(payload_b64)))
# Вывод:
# {'alg': 'HS256', 'typ': 'JWT'}
# {'sub': '1005', 'role': 'editor'}

В данных видно поле role со значением editor — именно его сервер использует для авторизации, а sub (subject) — это идентификатор пользователя. Подпись мы не проверяли, но на боевом сервере проверка подписи обязательна: без нее злоумышленник подставит себе любую роль. И раз payload читается кем угодно, класть в него секреты (пароли, номера карт) нельзя — токен защищает от подмены, но не прячет содержимое.

Роли и права: что можно после входа

После того как личность подтверждена, авторизация опирается на модель прав. Самая распространенная — RBAC (role-based access control, управление доступом на основе ролей). Права привязывают не к каждому пользователю по отдельности, а к роли, а роль уже выдают пользователю.

Такая модель удобна: чтобы дать сотруднику права редактора, достаточно назначить роль, а не перечислять разрешения вручную. Есть и более гибкая модель ABAC (attribute-based access control), где решение зависит от атрибутов — отдела, времени суток, типа устройства. RBAC проще и покрывает большинство задач, ABAC берут там, где нужны тонкие правила.

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

Когда вход не удался, сервер обычно возвращает один из двух кодов, и по названию их легко перепутать:

• 401 Unauthorized — несмотря на слово «unauthorized», это про аутентификацию: система не поняла, кто вы (не вошли или токен недействителен). Решение — войти заново.
• 403 Forbidden — это уже про авторизацию: система знает, кто вы, но именно этого действия вам не разрешено. Повторный вход не поможет, нужны другие права.

Типовые причины отказа — неверный логин или пароль (проверьте раскладку и регистр), истекший токен или сессия, отозванный доступ, блокировка после нескольких неудачных попыток. Если пароль забыт, восстановление идет по ссылке «Забыли пароль?»: система шлет на привязанную почту или телефон ссылку для смены пароля.

FAQ

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

Токен и cookie — это одно и то же? Нет. Cookie — это способ, которым браузер хранит и отправляет данные серверу. Токен — это содержимое, признак входа. Токен часто кладут в cookie, но токен может жить и в памяти приложения, а в cookie может лежать просто идентификатор серверной сессии.

Безопасно ли входить через Google или Яндекс? Да, при входе через OAuth ваш пароль видит только сам поставщик, стороннему сайту он не передается. Вы даете сайту ограниченный доступ к части данных и можете отозвать его в настройках своего аккаунта.

Выводы

Авторизация — это выдача прав, а не проверка личности; проверкой личности занимается аутентификация, и держать эти понятия раздельно — главное в теме. Полная цепочка входа выглядит так: идентификация (кто вы себя называете), аутентификация (доказательство пароля или другого фактора), авторизация (что вам после этого разрешено). Факт входа система запоминает через сессию или токен, вход через сторонний сервис работает по OAuth 2.0, а права чаще всего раздают по ролям через RBAC. Понимая эту схему, вы легче разберетесь и с ошибками входа, и с настройкой доступа в собственных проектах.